jiebi/CodeConvo huggingface dataset:
Change:
I got this error on my code even though it did not have any in it. Also, it seems to only happen on crates. Just a is enough to reproduce it. rust playground: The bug also happens on and versions of the compiler. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh, I think it's worth noting that if the code is refatored as: The bug ceases to happen.
I think duplicated of ?
this one doesn't need nightly to trigger
The code in works for me
right, because it's a different problem and only triggers with .
The issue seems to be that the gets desugared to a , which is currently unexpected in an branch. claim

Discussion:
fn print_else(&mut self, els: Option<&hir::Expr<'_>>) { match els { <del> Some(_else) => { match _else.kind { </del> <ins> Some(else_) => { match else_.kind { </ins> // "another else-if" hir::ExprKind::If(ref i, ref then, ref e) => { self.cbox(INDENT_UNIT - 1);

self.s.word(" else "); self.print_block(&b) } <ins> hir::ExprKind::Match(ref expr, arms, _) => { // else if let desugared to match assert!(arms.len() == 2, "if let desugars to match with two arms"); self.s.word(" else "); self.s.word("{"); self.cbox(INDENT_UNIT); self.ibox(INDENT_UNIT); self.word_nbsp("match"); self.print_expr_as_cond(&expr); self.s.space(); self.bopen(); for arm in arms { self.print_arm(arm); } self.bclose(expr.span); self.s.word("}"); } </ins> // BLEAH, constraints would be great here _ => { panic!("print_if saw if with weird alternative");

<ins> // https://github.com/rust-lang/rust/issues/82329 // compile-flags: -Zunpretty=hir,typed // check-pass pub fn main() { if true { } else if let Some(a) = Some(3) { } } </ins>

<ins> #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; // https://github.com/rust-lang/rust/issues/82329 // compile-flags: -Zunpretty=hir,typed // check-pass pub fn main() ({ (if (true as bool) ({ } as ()) else {match ((Some as fn(i32) -> Option<i32> {Option::<i32>::Some})((3 as i32)) as Option<i32>) { Some(a) => { } _ => { } }} as ()) } as ()) </ins>

<ins> // https://github.com/rust-lang/rust/issues/84434 // check-pass use std::path::Path; struct A { pub func: fn(check: bool, a: &Path, b: Option<&Path>), } const MY_A: A = A { func: |check, a, b| { if check { let _ = (); } else if let Some(parent) = b.and_then(|p| p.parent()) { let _ = (); } }, }; fn main() {} </ins>
Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: For some reason, this doesn't happen for all traits in . Eg Just gives Version: 1.53.0-nightly (2021-04-22 ) <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --
Some discussion on Discord suggests that might be a culprit. Trying with the variant produces as expected. So it looks like the trait bound is being honored for the search for the method, which is defined in the block, but not for the search for the method, which is defined in definition.
I suggest retitling this to "Compiler incorrectly (and inconsistently) finds methods on ".
I'd also like to suggest adding D-newcomer-roadblock because I've seen several other newcomers on Discord run into this confusing diagnostic.
I tried to replicate the incorrect diagnostic with a more minimal case than . It looks like it depends on the borrow mode of the receiver. This code : produces these errors: is a required trait method that takes a ref to , similar to (the doesn't seem necessary to exhibit these diagnostics). is a default trait method that moves , similar to most of the methods. It seems like a default trait method that moves is necessary to trigger this incorrect diagnostic. is a default trait method that takes a ref to , similar to . I've built a debugging version of the compiler and I'm trying to understand the debug logs for the trait and typechecking systems.
To elaborate on my prior comment: newcomers seem likely to encounter and be confused by this diagnostic. I ran into it myself by trying to call methods directly on , and I've seen several others be confused by that. I think I've also seen newcomers be confused by trying to call methods directly on arrays. label +D-newcomer-roadblock

Discussion:
<ins> fn main() { let x: i32 = 1; println!("{:?}", x.count()); //~ ERROR is not an iterator } </ins>

<ins> error[E0599]: `i32` is not an iterator --> $DIR/issue-84495.rs:3:24 | LL |     println!("{:?}", x.count()); |                        ^^^^^ `i32` is not an iterator | = note: the following trait bounds were not satisfied: `i32: Iterator` which is required by `&mut i32: Iterator` error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>
Change:
We are getting a duplicate symbol build error when compiling with . The error itself is (Full build with a RUSTBACKTRACE) The demangled symbol is That type referenced is from the predicatescore public crate, but unfortunately we have not yet narrowed down a reproduction beyond doing the full build. Believe this to be related to (specifically comment) cc:
Although there's nothing that looks like a cause, the actual code change that triggered the build failure was

Discussion:
Some(assoc_name), )); for (super_predicate, _) in super_predicates.predicates { <del> let bound_predicate = super_predicate.kind(); let subst_predicate = super_predicate .subst_supertrait(tcx, &bound_predicate.rebind(trait_ref.skip_binder())); </del> <ins> let subst_predicate = super_predicate.subst_supertrait(tcx, &trait_ref); </ins> if let Some(binder) = subst_predicate.to_opt_poly_trait_ref() { stack.push(binder.value); }

{ let mut computation = FlagComputation::new(); <ins> if !value.bound_vars().is_empty() { computation.flags = computation.flags | TypeFlags::HAS_RE_LATE_BOUND; } </ins> f(&mut computation, value.skip_binder()); self.add_flags(computation.flags);

<ins> // build-pass // compile-flags: --edition 2018 // compile-flags: --crate-type rlib use std::future::Future; async fn handle<F>(slf: &F) where F: Fn(&()) -> Box<dyn for<'a> Future<Output = ()> + Unpin>, { (slf)(&()).await; } fn main() {} </ins>

<ins> // run-pass // compile-flags: -Zsymbol-mangling-version=v0 pub fn f<T: ?Sized>() {} pub trait Frob<T: ?Sized> {} fn main() { f::<dyn Frob<str>>(); f::<dyn for<'a> Frob<str>>(); } </ins>
Change:
I tried this code: I expected to see this happen: An error message about exceeding some recursion limit Instead, this happened: Tested on stable 1.51.0 + <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that the crash also occurs without . Based on testing with Godbolt, this doesn't seem to be a regression, or at least not a recent one.
Assigning as part of the prioritization working group discussion and removing . modify labels -I-prioritize +P-medium
Issue might be in this line: Calls , which then calls : And sets to , which would result in stack overflow because the recursion limit is never reached.
claim
Bug is confusing to track down, so I am no longer working on this. For people who are interested, here is the log when the loop is encountered: release-assignment
The issue is part of a bigger problem, that seems to ignore the recursion limit. This snippet below compiles successfully instead of reporting an error:
Seems to be a regression between and by testing on Godbolt. I suspect from caused the regression, but I'm not sure. label regression-untriaged

Discussion:
pub fn fully_expand_fragment(&mut self, input_fragment: AstFragment) -> AstFragment { let orig_expansion_data = self.cx.current_expansion.clone(); let orig_force_mode = self.cx.force_mode; <del> self.cx.current_expansion.depth = 0; </del> // Collect all macro invocations and replace them with placeholders. let (mut fragment_with_placeholders, mut invocations) =

}; let ExpansionData { depth, id: expn_id, .. } = invoc.expansion_data; <ins> let depth = depth - orig_expansion_data.depth; </ins> self.cx.current_expansion = invoc.expansion_data.clone(); self.cx.force_mode = force;

<ins> // Regression test for #84632: Recursion limit is ignored // for builtin macros that eagerly expands. #![recursion_limit = "15"] macro_rules! a { () => (""); (A) => (concat!("", a!())); (A, $($A:ident),*) => (concat!("", a!($($A),*))) //~^ ERROR recursion limit reached //~| HELP consider adding } fn main() { a!(A, A, A, A, A); a!(A, A, A, A, A, A, A, A, A, A, A); } </ins>

<ins> error: recursion limit reached while expanding `concat!` --> $DIR/issue-84632-eager-expansion-recursion-limit.rs:8:28 | LL |     (A, $($A:ident),*) => (concat!("", a!($($A),*))) |                            ^^^^^^^^^^^^^^^^^^^^^^^^ ... LL |     a!(A, A, A, A, A, A, A, A, A, A, A); |     ------------------------------------ in this macro invocation | = help: consider adding a `#![recursion_limit="30"]` attribute to your crate (`issue_84632_eager_expansion_recursion_limit`) = note: this error originates in the macro `a` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </ins>
Change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: x.py patches stage0/cargo Instead, this happened: x.py tries to patch ci-rustc/cargo, fails, and never patches stage0/cargo, causing a build failure. In particular, does not exist: and stage0/bin/cargo is never patched.
Hmm this seems to be related to caching somehow - if I delete stage0/ altogether it works properly.
I was not able to replicate this :( checking out without clearing the cache didn't reproduce the bug.
And now it broke again :/ maybe it only happens on completely fresh builds?
It did try to patch cargo this time, though:
Ok, this looks suspicious: it's downloading the component, but cargo does not show up in ci-rustc/bin/cargo. I think the issue is it successfully patches stage0 cargo, extracts ci-rustc cargo to the wrong folder, overwriting the patched version, and then tries to patch the correct folder. I think the fix is to just not try to download cargo for the ci-rustc toolchain, it's not necessary in the first place.

Discussion:
filename = "rustc-{}-{}{}".format(rustc_channel, self.build, tarball_suffix) self._download_component_helper(filename, "rustc", tarball_suffix, stage0) <del> filename = "cargo-{}-{}{}".format(rustc_channel, self.build, tarball_suffix) self._download_component_helper(filename, "cargo", tarball_suffix) if not stage0: </del> <ins> # download-rustc doesn't need its own cargo, it can just use beta's. if stage0: filename = "cargo-{}-{}{}".format(rustc_channel, self.build, tarball_suffix) self._download_component_helper(filename, "cargo", tarball_suffix) self.fix_bin_or_dylib("{}/bin/cargo".format(bin_root)) else: </ins> filename = "rustc-dev-{}-{}{}".format(rustc_channel, self.build, tarball_suffix) self._download_component_helper( filename, "rustc-dev", tarball_suffix, stage0

self.fix_bin_or_dylib("{}/bin/rustc".format(bin_root)) self.fix_bin_or_dylib("{}/bin/rustdoc".format(bin_root)) <del> self.fix_bin_or_dylib("{}/bin/cargo".format(bin_root)) </del> lib_dir = "{}/lib".format(bin_root) for lib in os.listdir(lib_dir): if lib.endswith(".so"):
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!

Discussion:
<del> Subproject commit 5faf5a5ca059f6eb067fc86e47480f5668ac6e8c </del> <ins> Subproject commit 41f3fe64317a6ef144d2ac33e4e5870d894d6038 </ins>
Change:
Hi! I tried to compile my code and got a compiler crash. , stable, problem is present: , beta, problem still present: , nightly, problem still present: <details<summary<strongBacktrace</strong</summary<p</p</details
Seems to be a duplicate of according to the error message itself, but I can't see a const generic expression anywhere. Maybe in the serialport crate. I try to minimize this one.
MCVE:
It seems to be const related because of . If I replace it with this won't panic anymore and is const Regression in nightly-2019-11-29 between ... stable versions: 1.40.0 and 1.41.0 So, this one is different to the linked issue, therefore let's ping it to the people modify labels: regression-from-stable-to-stable
Is this blocking an update of the compiler on existing code or is it just experimentation?
This is just something I ran into yesterday while coding. With finding that replacing with , I can continue with my code. :) Does that answer your question? I don't totally understand it. :(
Assigning priority as discussed as part of the and removing . thanks for the feedback, don't worry, we simply wanted to clarify if the suggested workaround allows you to move on (which you confirmed) or if the issue was blocking. label -I-prioritize +P-medium
I also had this issue happen to me () and I was able to reproduce it with this: I think it's worth noting that the error goes away if we either: we remove the field from (or just remove the from the function signature and replace the with just ); we substitute both calls to in second 's field initialization with a literal (e.g. for example);
This is no longer ICE with the latest nightly, I think is the fix. Marking as .
Hi, I've made a PR that adds a test for this, pretty much copy/pastes 's MCVE

Discussion:
<ins> // build-pass trait Foo {} struct Bar { bytes: &'static [u8], func: fn(&Box<dyn Foo>), } fn example(_: &Box<dyn Foo>) {} const BARS: &[Bar] = &[ Bar { bytes: "0".as_bytes(), func: example, }, Bar { bytes: "0".as_bytes(), func: example, }, ]; fn main() { let x = todo!(); for bar in BARS { (bar.func)(&x); } } </ins>
Change:
The output: In the second , the first print statement prints out the right answer, but reading for the second time yields garbage (perhaps is wrongly getting moved out of here even though it's a ref binding?). The third just prints out garbage.
there must have been some heroic test-case minimization behind the scenes of this issue
Indeed, at first I thought the problem was process spawning... it's actually the arguments to process spawning that go wrong, even before any process gets spawned!
I thought this might be related to , but it's not; the test still fails when compiling from a branch that includes the fix for .
Modernized testcase: New output:
This appears to have been fixed, flagging as needstest.

Discussion:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // xfail-test </del> pub fn main() { <del> // This is ok </del> match &[(~5,~7)] { ps => { let (ref y, _) = ps[0]; <del> println!("1. y = {}", **y); </del> assert!(**y == 5); } } <del> // This is not entirely ok </del> match Some(&[(~5,)]) { Some(ps) => { let (ref y,) = ps[0]; <del> println!("2. y = {}", **y); if **y != 5 { println!("sadness"); } </del> <ins> assert!(**y == 5); </ins> } None => () } <del> // This is not ok </del> match Some(&[(~5,~7)]) { Some(ps) => { let (ref y, ref z) = ps[0]; <del> println!("3. y = {} z = {}", **y, **z); </del> assert!(**y == 5); <ins> assert!(**z == 7); </ins> } None => () } }
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Some error message changes (cc ) broke Miri, but some "null pointer is not allowed for this operation" changes look... wrong? For example: (and many more) They are all not .
Yeah my patch makes no sense... working on a fix.
I don't think the toolstate is fixed: ! But it's just error message differences: claim

Discussion:
<del> Subproject commit 67c04afc251ad7d80ea22e2056c93349e7e9df58 </del> <ins> Subproject commit 38b5f236d2c62ff0b1017efd183b193f5db33123 </ins>
Change:
I don't have time to make an MCVE right now. Stable and beta: ! Nightly and 1.51: ! 50: ! Either the methods should be documented, or they shouldn't be linked to. cc I suspect this is regression from the backports of
First of all, here's an MVCE: Nevermind, I see this is getting discussed in
Removed , this is not a 1.53 regression.
sure, then it's a stable-to-stable regression then. It first regressed in 1.52.

Discussion:
out.push_str("</div>"); } } <del> // Recurse into any further impls that might exist for `target` if let Some(target_did) = target.def_id_full(c) { if let Some(target_impls) = c.impls.get(&target_did) { if let Some(target_deref_impl) = target_impls .iter() .filter(|i| i.inner_impl().trait_.is_some()) .find(|i| i.inner_impl().trait_.def_id_full(c) == c.deref_trait_did) { sidebar_deref_methods(cx, out, target_deref_impl, target_impls); } } } </del> } }

<ins> use std::ops::Deref; pub struct A {} impl A { pub fn foo_a(&self) {} } pub struct B {} impl B { pub fn foo_b(&self) {} } pub struct C {} impl C { pub fn foo_c(&self) {} } // @has recursive_deref_sidebar/struct.A.html '//div[@class="sidebar-links"]' 'foo_b' impl Deref for A { type Target = B; fn deref(&self) -> &B { todo!() } } // @!has recursive_deref_sidebar/struct.A.html '//div[@class="sidebar-links"]' 'foo_c' impl Deref for B { type Target = C; fn deref(&self) -> &C { todo!() } } </ins>

<ins> use std::ops::Deref; pub struct A; pub struct B; // @has recursive_deref/struct.A.html '//code' 'impl Deref for A' impl Deref for A { type Target = B; fn deref(&self) -> &Self::Target { panic!() } } // @has recursive_deref/struct.B.html '//code' 'impl Deref for B' impl Deref for B { type Target = A; fn deref(&self) -> &Self::Target { panic!() } } </ins>
Change:
Note that must not exist in order to reproduce this error: The first error is what I would expect, but the second is a bit confusing and weird: Perhaps instead of emitting (/ERROR/)delayspanbug` since an error should have already occurred. If for some reason an error had not already been emitted, the compiler would crash; otherwise, it would just show the original error. Originally posted by in
Note that is stable now (though it hasn't reached the stable channel yet), so this no longer requires a feature flag.
Mentoring instructions: in , check if the token is a and the expression is an error; if so, use instead of .
Hi I was searching for a first issue and i have a question : What does ? Because the function that you pin must return a but has return type Sorry if i misread something
delayspanbug means "if the compiler finishes running without first reporting another error, panic". It's useful here because error tokens should always report in an error being reported. I think anything you return is probably fine as long as it doesn't cause further cascading errors :)
i fixed it but for adding a test case : i run into an edge case the output message of the macro : include_str! is not normalized with $DIR the ui test is working only for me. Have you a tip or i have to create an issue ? Thanks
you can use : https://rustc-dev- But I'm surprised $DIR doesn't work :/ that does seem like a bug.
Sorry I was not clear : the $DIR is working for the But the path is not replace for the error comment in the because the path read by include_str is in the error message
don't put the whole name in the .rs file - you just need to put a substring. Something like .

Discussion:
pub(super) fn parse_lit(&mut self) -> PResult<'a, Lit> { self.parse_opt_lit().ok_or_else(|| { <ins> if let token::Interpolated(inner) = &self.token.kind { let expr = match inner.as_ref() { token::NtExpr(expr) => Some(expr), token::NtLiteral(expr) => Some(expr), _ => None, }; if let Some(expr) = expr { if matches!(expr.kind, ExprKind::Err) { self.diagnostic() .delay_span_bug(self.token.span, &"invalid interpolated expression"); return self.diagnostic().struct_dummy(); } } } </ins> let msg = format!("unexpected token: {}", super::token_descr(&self.token)); self.struct_span_err(self.token.span, &msg) })

<ins> // normalize-stderr-test: "couldn't read.*" -> "couldn't read the file" #![feature(extended_key_value_attributes)] #![doc = include_str!("../not_existing_file.md")] struct Documented {} //~^^ ERROR couldn't read fn main() {} </ins>

<ins> error: couldn't read the file --> $DIR/extented-attribute-macro-error.rs:4:10 | LL | #![doc = include_str!("../not_existing_file.md")] |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: this error originates in the macro `include_str` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </ins>
Change:
(From the Playground.) Note that the uses of , , and don't include their lifetimes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
let mut nonelided_generic_args: bool = false; let elide_lifetimes = generic_args.args.iter().all(|arg| match arg { <del> GenericArg::Lifetime(lt) => lt.is_elided(), </del> <ins> GenericArg::Lifetime(lt) if lt.is_elided() => true, GenericArg::Lifetime(_) => { nonelided_generic_args = true; false } </ins> _ => { nonelided_generic_args = true; true

<ins> #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; // Test to print lifetimes on HIR pretty-printing. // pretty-compare-only // pretty-mode:hir // pp-exact:issue-85089.pp trait A<'x> { } trait B<'x> { } struct Foo<'b> { bar: &'b dyn for<'a> A<'a>, } impl <'a> B<'a> for dyn for<'b> A<'b> { } impl <'a> A<'a> for Foo<'a> { } </ins>

<ins> // Test to print lifetimes on HIR pretty-printing. // pretty-compare-only // pretty-mode:hir // pp-exact:issue-85089.pp trait A<'x> {} trait B<'x> {} struct Foo<'b> { pub bar: &'b dyn for<'a> A<'a>, } impl<'a> B<'a> for dyn for<'b> A<'b> {} impl<'a> A<'a> for Foo<'a> {} </ins>