jiebi/CodeConvo huggingface dataset:
Change:
cx.llsizingtypes().borrow_mut().insert(t, llsizingty); // FIXME(eddyb) Temporary sanity check for ty::layout. <del> let layout = cx.tcx().normalizing_infer_ctxt(Reveal::All).enter(|infcx| { t.layout(&infcx) }); match layout { Ok(layout) => { if !type_is_sized(cx.tcx(), t) { if !layout.is_unsized() { bug!("layout should be unsized for type `{}` / {:#?}", t, layout); } // Unsized types get turned into a fat pointer for LLVM. return llsizingty; } let r = layout.size(&cx.tcx().data_layout).bytes(); let l = machine::llsize_of_alloc(cx, llsizingty); if r != l { bug!("size differs (rustc: {}, llvm: {}) for type `{}` / {:#?}", r, l, t, layout); } let r = layout.align(&cx.tcx().data_layout).abi(); let l = machine::llalign_of_min(cx, llsizingty) as u64; if r != l { bug!("align differs (rustc: {}, llvm: {}) for type `{}` / {:#?}", r, l, t, layout); } } Err(e) => { bug!("failed to get layout for `{}`: {}", t, e); </del> <ins> let layout = cx.layout_of(t); if !type_is_sized(cx.tcx(), t) { if !layout.is_unsized() { bug!("layout should be unsized for type `{}` / {:#?}", t, layout); </ins> } <ins> // Unsized types get turned into a fat pointer for LLVM. return llsizingty; } let r = layout.size(&cx.tcx().data_layout).bytes(); let l = machine::llsize_of_alloc(cx, llsizingty); if r != l { bug!("size differs (rustc: {}, llvm: {}) for type `{}` / {:#?}", r, l, t, layout); </ins> } <ins> let r = layout.align(&cx.tcx().data_layout).abi(); let l = machine::llalign_of_min(cx, llsizingty) as u64; if r != l { bug!("align differs (rustc: {}, llvm: {}) for type `{}` / {:#?}", r, l, t, layout); } </ins> llsizingty }

Discussion:
On stable, beta, and nightly, the follow code prints followed by : CC
This is probably for drop flags, in which case it should get fixed by
Reduced:
where would there be a drop flag here?
My point isn't that there is, but that the code assumes all trait objects have drop flags. I could be wrong though, it might be a bug in the alignment logic.
Not fixed by , will have to investigate further.
Uhhhh, the computation starts with: Which is completely wrong, because you want no trailing padding, i.e. should be . EDIT: getting a field pointer might also be broken, needs looking into. EDIT2: to handle the "minimum size" needed to compute the field offset, so that works.
Change:
fold_item_tag  = bind identity_fold_item_tag[ENV](_,_,_,_,_,_), fold_item_obj  = bind identity_fold_item_obj[ENV](_,_,_,_,_,_,_), <ins> fold_view_item_use = bind identity_fold_view_item_use[ENV](_,_,_,_,_), fold_view_item_import = bind identity_fold_view_item_import[ENV](_,_,_,_), </ins> fold_block = bind identity_fold_block[ENV](_,_,_), fold_fn = bind identity_fold_fn[ENV](_,_,_,_,_), fold_mod = bind identity_fold_mod[ENV](_,_),

Discussion:
I was trying to build the stdlibs for the target like this: However, the build fails with the following error: Here is the full build log: I'm using Xubuntu 15.10. At the time of building, the Rust master was at .
Unfortunately is a which means that we don't guarantee that it builds in-tree right now. Patches are certainly welcome to fix this, however! We tend to not keep issues tracking build support for all Tier 3 platforms, however, so I'm going to close this. If you're interested in promoting this to at least tier 2 you could also help modify out to be able to support this target!
Change:
ast::BindByRef(_) => { // By ref binding: the value of the variable <del> // is the pointer `val` itself. Store(bcx, val, llval); </del> <ins> // is the pointer `val` itself or fat pointer referenced by `val` if type_is_fat_ptr(bcx.tcx(), ty) { expr::copy_fat_ptr(bcx, val, llval); } else { Store(bcx, val, llval); } </ins> bcx } }

Discussion:
I've tried to write: The line above gives LLVM assertion. I think this must show some syntax error.
Change:
<del> // Copyright 2012 The Rust Project Developers. See the COPYRIGHT </del> <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT </ins> // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. //

Discussion:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

This code wrongly states "expected constant integer for repeat count, but non-constant path in constant expression" This one works
accidentally fixed in
Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // no-prefer-dynamic #![feature(proc_macro)] #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn foo(attr: TokenStream, item: TokenStream) -> TokenStream { drop(attr); assert_eq!(item.to_string(), "fn foo() { }"); "fn foo(&self);".parse().unwrap() } </ins>

Discussion:
Given this procedural macro: and this crate: Building: I saw no output :( I find that is resolved, it just doesn't seem to get expanded!
cc
I saw this earlier and I've been thinking about it. I don't remember anything special in the invocation collector concerning trait methods though. Isn't there some codepath that strips attributes from trait methods, stuff like that doesn't make sense on them?
Not that I know of -- I'll do some debugging to figure out where the issue is (, , etc.).
Ok I've debugged this a bit and I think I've narrowed it down to resolve. The attribute is first resolved as and then resolved as which triggers to I think fill in a "dummy" invocation, which ends up effectively stripping the item. Still trying to figure out why this isn't resolved right.
In attempting to debug further I think I'm pretty far out of my league here. I think what's happening is that resolution is attempting to resolve in the "trait's namespace", but that predictably fails and it in theory should go up to the parent module namespace and then do resolution there again, right? What I've found though is that is returning because while the trait does have a parent which presumably points to the crate's module they both have an of . The loop in currently enforces which means that it can't go up one level. Does that ring any bells or Or maybe this is all a red herring?
Haven't looked into this yet, but this explanation makes sense. I believe the issue here is that shouldn't be called with a trait module. enforces for modules since in the normal, non-hygienic case, modules don't have lexical parents (except for the prelude). That is, However, due to hygiene, the following resolves: If this issue is as I expect, I can fix quickly tomorrow.
Ah ok, I'll leave you to it as I suspect you'll find it much more quickly than I will! If you run out of time though just let me know and I will resume digging!
Change:
/// # Examples /// /// ``` <del> /// #![feature(btree_retain)] </del> /// use std::collections::BTreeMap; /// /// let mut map: BTreeMap<i32, i32> = (0..8).map(|x| (x, x*10)).collect();

Discussion:
This is a tracking issue for and (part of rust-lang/rfcs). The feature gate for the issue is . [x] Implement the RFC [x] FCP [ ] Adjust documentation [ ] Stabilization PR Is the performance of the current implementation (based on ) good enough to be useful? Concern raised in . Initial implementation:
We discussed this in today's meeting. We'd like to see a comment documenting the performance characteristics of this (as well as a corresponding update to ), and suggesting that this might not be what you want if you're removing a substantial number of elements. Beyond that documentation, though, we'd be happy to see this stable. merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Change:
let env = match self.env { None => None, Some(ref env_map) => <del> Some(env_map.iter().collect::<Vec<_>>()) </del> <ins> Some(env_map.iter() .map(|(&EnvKey(ref key), val)| (key, val)) .collect::<Vec<_>>()) </ins> }; let cfg = ProcessConfig { program: &self.program,

Discussion:
The following program demonstrates the problem: When compiled and executed on WIndows, it randomly displays either 'foo' or 'BAR'. This happens because process::Command represents environment block as a HasMap<CString, CString, so it treats "foo" and "FOO" as different variables, whereas Windows considers them to be the same one. When child process is spawned, both get into the environment block, however Windows keeps only the last one.
Change:
"checking for inline asm in case the target doesn't support it", || no_asm::check_crate(sess, &krate)); <del> // One final feature gating of the true AST that gets compiled // later, to make sure we've got everything (e.g. configuration // can insert new attributes via `cfg_attr`) time(time_passes, "complete gated feature checking 2", || { </del> <ins> // Needs to go *after* expansion to be able to check the results of macro expansion. time(time_passes, "complete gated feature checking", || { </ins> sess.track_errors(|| { let features = syntax::feature_gate::check_crate(sess.codemap(), &sess.parse_sess.span_diagnostic,

Discussion:
Macro-expanded unconfigured items are gated feature checked, but ordinary unconfigured items are not. For example, the following should compile, ... If we manually expand , it always compiles:
It looks like this was (introduced in ), but I don't think it's a good idea. cc cc
There are arguments on about why this is not a good idea: is typically used by crates that need to build against both stable and nightly and use nightly-specific features when available (the most important example that I have in mind is syntax extensions using plugins on nightly and syntex on stable). Checking for use of gated features inside this -guarded code will break those crates, and it's not a good thing, this use case is actually useful. This check pass should be removed.
cc
Change:
} } <del> /// Matches `'-' lit | lit (cf. parser::Parser::parse_literal_maybe_minus)`, /// or paths for ranges. // // FIXME: do we want to allow `expr -> pattern` conversion to create path expressions? // That means making this work: // // ```rust,ignore (FIXME) // struct S; // macro_rules! m { //     ($a:expr) => { //         let $a = S; //     } // } // m!(S); // ``` fn check_expr_within_pat(&self, expr: &Expr, allow_paths: bool) { match expr.kind { ExprKind::Lit(..) | ExprKind::ConstBlock(..) | ExprKind::Err => {} ExprKind::Path(..) if allow_paths => {} ExprKind::Unary(UnOp::Neg, ref inner) if matches!(inner.kind, ExprKind::Lit(_)) => {} _ => self.err_handler().span_err( expr.span, "arbitrary expressions aren't allowed  in patterns", ), } } </del> fn check_late_bound_lifetime_defs(&self, params: &[GenericParam]) { // Check only lifetime parameters are present and that the lifetime // parameters that are present have no bounds.

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Note: this only occurs when the type of the code block is a result. Removing the line and swapping for does not yield the ICE. //! use rustice::sub; //! //! let x = sub::makestruct()?; //! //! assert!(matches!(x, sub::En::A(sub::B { inner: vec![], .. }))); //! Ok::<(), &'static str(()) //! <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: and after a rustup, (still getting the same ICE): <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Here's a reproduction without rustdoc involved:
Minimized:
Change:
./x.py doc --stage 1", ); } <del> "run" => { </del> <ins> "run" | "r" => { </ins> subcommand_help.push_str( "n Arguments:

Discussion:
currently supports , and a few others even though not so discoverable (). It would be good to let supports the aliases supported by , such as , and such. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
# impl Circle for CircleStruct { fn radius(&self) -> f64 { (self.area() / PI).sqrt() } } # impl Shape for CircleStruct { fn area(&self) -> f64 { PI * square(self.radius) } } <del> let concrete = @CircleStruct{center:Point{x:3.0,y:4.0},radius:5.0}; let mycircle: @Circle = concrete as @Circle; </del> <ins> let concrete = ~CircleStruct{center:Point{x:3.0,y:4.0},radius:5.0}; let mycircle: ~Circle = concrete as ~Circle; </ins> let nonsense = mycircle.radius() * mycircle.area(); ~~~

Discussion:
Their continued existence in the tutorial is causing confusion over what the status of this feature is. Let all the world know that managed pointers are relegated to the dustbin of history!
It's unclear to me if the tutorial is being rewritten from scratch by Mozilla. There's not much motivation for anyone to work on it if it's just going to be thrown out.
That may be true, but if a good samaritan wanted to do just enough work to delete mentions of them from the current tutorial, it would not be unappreciated.
Hi, I am the one who asked about this initially. I have started to work on it now.
At this point I do think it's worthwhile to keep maintaining the tutorial. Even if it doesn't survive as the tutorial, it does contain a lot of information that will end up disseminated elsewhere.
Not maintaining the tutorial leads to a growing collection of inaccurate or wrong information. Removing it could give newcomers a better first-time experience of Rust.
Change:
<ins> error[E0700]: hidden type for `Opaque<'static>` captures lifetime that does not appear in bounds --> $DIR/different_args_considered_equal2.rs:9:9 | LL | pub type Opaque<'a> = impl Sized; |                       ---------- opaque type defined here LL | LL | fn get_one<'a>(a: *mut &'a str) -> impl IntoIterator<Item = Opaque<'a>> { |            -- hidden type `*mut &'a str` captures the lifetime `'a` as defined here ... LL |         None::<Opaque<'static>> |         ^^^^^^^^^^^^^^^^^^^^^^^ | help: to declare that `impl IntoIterator<Item = Opaque<'a>>` captures `'a`, you can add an explicit `'a` lifetime bound | LL | fn get_one<'a>(a: *mut &'a str) -> impl IntoIterator<Item = Opaque<'a>> + 'a { |                                                                         ++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0700`. </ins>

Discussion:
The following should not compile. Adapted from . This is a quick issue, I did not have the chance to look into it deeper but I guess it affects ATPIT as well. cc
This used to be an error in , but then incorrectly accepted in .
Change:
} #[derive(Subdiagnostic)] <ins> #[note(resolve_macro_defined_later)] pub(crate) struct MacroDefinedLater { #[primary_span] pub(crate) span: Span, } #[derive(Subdiagnostic)] #[label(resolve_consider_move_macro_position)] pub(crate) struct MacroSuggMovePosition { #[primary_span] pub(crate) span: Span, pub(crate) ident: Ident, } #[derive(Subdiagnostic)] </ins> #[note(resolve_missing_macro_rules_name)] pub(crate) struct MaybeMissingMacroRulesName { #[primary_span]

Discussion:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!
Change:
use super::type_variable::TypeVariableValue; use super::unify_key::{ConstVarValue, ConstVariableValue}; use super::unify_key::{ConstVariableOrigin, ConstVariableOriginKind}; <ins> use super::unify_key::replace_if_possible; </ins> use crate::hir::def_id::DefId; use crate::mir::interpret::ConstValue;

Discussion:
<short summary of the bugI tried this code: I expected to see this happen: It should build. Instead, this happened: rustc crashed with: Possible workaround: replace with . playground: rustc version: 1.39.0-nightly 2019-09-15
cc
Also ICEs without explicit feature gate enabled :/
Change:
error: to use a constant of type `consts::CustomEq` in a pattern, `consts::CustomEq` must be annotated with `#[derive(PartialEq, Eq)]` <del> --> $DIR/cross-crate-fail.rs:9:9 </del> <ins> --> $DIR/cross-crate-fail.rs:13:9 </ins> | LL |         consts::SOME => panic!(), |         ^^^^^^^^^^^^ error: to use a constant of type `consts::CustomEq` in a pattern, `consts::CustomEq` must be annotated with `#[derive(PartialEq, Eq)]` <del> --> $DIR/cross-crate-fail.rs:9:9 </del> <ins> --> $DIR/cross-crate-fail.rs:21:9 | LL |         <Defaulted as consts::AssocConst>::SOME  => panic!(), |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: to use a constant of type `consts::CustomEq` in a pattern, `consts::CustomEq` must be annotated with `#[derive(PartialEq, Eq)]` --> $DIR/cross-crate-fail.rs:13:9 </ins> | LL |         consts::SOME => panic!(), |         ^^^^^^^^^^^^ <del> error: aborting due to 2 previous errors </del> <ins> error: to use a constant of type `consts::CustomEq` in a pattern, `consts::CustomEq` must be annotated with `#[derive(PartialEq, Eq)]` --> $DIR/cross-crate-fail.rs:21:9 | LL |         <Defaulted as consts::AssocConst>::SOME  => panic!(), |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 4 previous errors </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --I don't have a reasonable sized reproducer yet. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: Regression occurred ~between ..~ in () <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Updated the issue description with a complete backtrace that has full line info (435 frames deep!)
Update: I bisected this to () cc
it looks like this match needs to be updated somehow: Does this bug report contain enough information to understand the problem, or do you need an MCVE?
Could you reproduce but debug print the the scrutinee in the arm?
I'm surprised since we should return before calling for all other types. It must be one of the variants. That means we're using the of the associated const definition instead of the declaration. Maybe a defaulted associated const? I dunno.
Indeed, here's the source for the item being checked (specifically, ):
Ah okay. We should already be encoding the s for associated type defaults. If so, just adding an would resolve the issue. I think I can synthesize a test case from here though, so don't worry about reducing further. Thanks for the help!
No problem! Since I'd kicked this off already, here's the debug print:
Change:
<ins> error[E0277]: can't compare `PriorityQueue<T>` with `PriorityQueue<T>` --> $DIR/issue-104884-trait-impl-sugg-err.rs:13:10 | LL | #[derive(PartialOrd, AddImpl)] |          ^^^^^^^^^^ no implementation for `PriorityQueue<T> == PriorityQueue<T>` | = help: the trait `PartialEq` is not implemented for `PriorityQueue<T>` note: required by a bound in `PartialOrd` --> $SRC_DIR/core/src/cmp.rs:LL:COL | LL | pub trait PartialOrd<Rhs: ?Sized = Self>: PartialEq<Rhs> { |                                           ^^^^^^^^^^^^^^ required by this bound in `PartialOrd` = note: this error originates in the derive macro `PartialOrd` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0277]: the trait bound `PriorityQueue<T>: Eq` is not satisfied --> $DIR/issue-104884-trait-impl-sugg-err.rs:13:22 | LL | #[derive(PartialOrd, AddImpl)] |                      ^^^^^^^ the trait `Eq` is not implemented for `PriorityQueue<T>` | note: required by a bound in `Ord` --> $SRC_DIR/core/src/cmp.rs:LL:COL | LL | pub trait Ord: Eq + PartialOrd<Self> { |                ^^ required by this bound in `Ord` = note: this error originates in the derive macro `AddImpl` (in Nightly builds, run with -Z macro-backtrace for more info) error[E0277]: can't compare `T` with `T` --> $DIR/issue-104884-trait-impl-sugg-err.rs:13:22 | LL | #[derive(PartialOrd, AddImpl)] |                      ^^^^^^^ no implementation for `T < T` and `T > T` | note: required for `PriorityQueue<T>` to implement `PartialOrd` --> $DIR/issue-104884-trait-impl-sugg-err.rs:13:10 | LL | #[derive(PartialOrd, AddImpl)] |          ^^^^^^^^^^ note: required by a bound in `Ord` --> $SRC_DIR/core/src/cmp.rs:LL:COL | LL | pub trait Ord: Eq + PartialOrd<Self> { |                     ^^^^^^^^^^^^^^^^ required by this bound in `Ord` = note: this error originates in the derive macro `AddImpl` which comes from the expansion of the derive macro `PartialOrd` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Given the following code: current output is: The last part of the suggestion is not valid Rust code and therefore should not be suggested like this. This problem occurs on the Playground on both stable and nightly with basically identical error messages. serde v1.0.147 requires such that will be . Otherwise the problem does not seem serde specific. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
do you know how to create a minimal case without ? so we may add it to unit testing. I give a fix and verified it's OK with my local testing, but I'm struggle to construct a minimal case without to reproduce it.
I assume this reproduces when using the same setup of derive macro implementing a trait while the implementation is missing bounds. I don't know if it is relevant that the derive macro produces a trait. Something along these lines, with the proc macro crate omitted.
yes, it's caused by derive macro.
emmmet this error