jiebi/CodeConvo huggingface dataset:
Change:
// An impl that has an erroneous const substitution should not specialize one // that is well-formed. <ins> #[derive(Clone)] </ins> struct S<const L: usize>; impl<const N: i32> Copy for S<N> {} <ins> //~^ ERROR the constant `N` is not of type `usize` </ins> impl<const M: usize> Copy for S<M> {} <del> //~^ ERROR conflicting implementations of trait `Copy` for type `S<_>` </del> fn main() {}

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. --<!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
// For cases like #95134 we would like to catch overflows early // otherwise they slip away away and cause ICE. let recursion_limit = self.tcx().recursion_limit(); <del> if !recursion_limit.value_within_limit(self.depth) { </del> <ins> if !recursion_limit.value_within_limit(self.depth) // HACK: Don't overflow when running cargo doc see #100991 && !self.tcx().sess.opts.actually_rustdoc { </ins> let obligation = Obligation::with_depth( self.cause.clone(), recursion_limit.0,

Discussion:
The diesel benchmark has been broken in some recent commit: ref:
The error seems to be caused (cc Curiously, this only happens in . Here's the error: The line where the error triggers is: You can reproduce this issue by: cloning the rustc-perf repo going to diesel-1.4.8 benchmark in that repo installing commit using running
How can I run this(rustc-perf repo) via locally built rustc?
might be related as well?
That indeed looks related, so should fix this ?
The comment also makes it look like will fix this.
Unfortunately, did not fix the issue. Using the build bors creates after merge , leads to the same error as above. to reproduce this, you just need to clone the rustc-perf repo and cd into . Then run and
Thanks, I will try to push a fix today.
I'm just gonna revert my original PR that introduced this overflow until I can create a version that works with diesel, given the perf regression of my "fix" and the remaining existence of this issue, so don't waste too much time on this.
I already found a fix
cc
I've started on minimizing this in , with the goal of removing the rustdoc special casing once I finish If someone could finish it up that would be extremely helpful - I think it's related to one of the impls on , if I define an identical trait in it doesn't overflow anymore. You can reproduce the overflow with .
Change:
<ins> // Copyright 2016 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. #![feature(rustc_attrs)] macro_rules! mac { {} => { #[cfg(attr)] mod m { #[lang_item] fn f() {} } } } mac! {} #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>

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:
<ins> // rust-lang/rust#83309: The compiler tries to suggest potential // methods that return `&mut` items. However, when it doesn't // find such methods, it still tries to add suggestions // which then fails an assertion later because there was // no suggestions to make. fn main() { for v in Query.iter_mut() { //~^ NOTE this iterator yields `&` references *v -= 1; //~^ ERROR cannot assign to `*v` which is behind a `&` reference //~| NOTE `v` is a `&` reference, so the data it refers to cannot be written } } pub struct Query; pub struct QueryIter<'a>(&'a i32); impl Query { pub fn iter_mut<'a>(&'a mut self) -> QueryIter<'a> { todo!(); } } impl<'a> Iterator for QueryIter<'a> { type Item = &'a i32; fn next(&mut self) -> Option<Self::Item> { todo!(); } } </ins>

Discussion:
Code that generated this error is available here: I am happy to spend some time trying to create a smaller repro but it will take me a few days. This error is reproducible on my machine. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
FYI, with this code compiled.
Minimized: Similar error was reported in . The issue is in code that attempts to suggest a different method, that might potentially return items. In that particular case there are no other suggestions to make, but code will attempt to emit diagnostic anyway, eventually failing the assertion: label: +E-easy
claim
label +regression-from-stable-to-beta
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Change:
.enumerate() .map(|(idx, e)| idx.wrapping_add(e)) .fuse() <del> .peekable() </del> .collect::<Vec<usize>>(), ); });

Discussion:
This code leads to an out of bounds write, makes the assert fail and triggers miri: The problem is that after cloning a the inner iterator can no longer be considered advanced, but the may still yield the peeked element without advancing it, thus breaking the contract of .
This can be fixed by either removing from or by changing the impl of to clone the exact state of rather than allocating a smaller one. The latter may be unnecessarily costly when cloning a mostly-exhausted iterator, but on the other hand it would preserve the optimization. So I'd try the first one first and do a perf run to see what the impact is (when it was introduced it mostly helped rustdoc) and try the latter if there's a significant regression.
It may also be possible to fix this by specializing on to look into its (if available) and do a custom clone of its source. I'll see if specialization is powerful enough to pull that off.
Hrm, I think it would be possible to do that but it would require some additional helper traits or methods tailored to just this use-case since doesn't know about . That's probably too much hackery for this optimization.
This also effects stable modify labels: regression-from-stable-to-stable
Is it a regression though? Marking as according to the . modify labels -I-prioritize +P-critical
Technically when was merged it broke any crate that used code like this (which is not that unexpected like exploting panics and stuff like that). In fact I found this bug due to a project written in only safe rust code that was segfaulting
Change:
/// /// ``` /// let a = [1, 2, 3, 4, 5]; <del> /// assert!(a.iter().fold(0, |a, &b| a + b) == 15); </del> <ins> /// assert!(a.iter().fold(0, |acc, &item| acc + item) == 15); </ins> /// ``` #[inline] #[stable(feature = "rust1", since = "1.0.0")]

Discussion:
This isn't a big deal but the documentation is slightly out of date for the variant of . Reference: The comment should read: I will fix this if I have time, otherwise it is a small tweak that someone looking to contribute could make. cc
I've taken the liberty of fixing that comment :)
can you open up a pull request please?
Yep, done! Is this the right way to do it?
Change:
debug!("regular_traits: {:?}", regular_traits); debug!("auto_traits: {:?}", auto_traits); <ins> // Transform a `PolyTraitRef` into a `PolyExistentialTraitRef` by // removing the dummy `Self` type (`trait_object_dummy_self`). let trait_ref_to_existential = |trait_ref: ty::TraitRef<'tcx>| { if trait_ref.self_ty() != dummy_self { // FIXME: There appears to be a missing filter on top of `expand_trait_aliases`, // which picks up non-supertraits where clauses - but also, the object safety // completely ignores trait aliases, which could be object safety hazards. We // `delay_span_bug` here to avoid an ICE in stable even when the feature is // disabled. (#66420) tcx.sess.delay_span_bug(DUMMY_SP, &format!( "trait_ref_to_existential called on {:?} with non-dummy Self", trait_ref, )); } ty::ExistentialTraitRef::erase_self_ty(tcx, trait_ref) }; </ins> // Erase the `dummy_self` (`trait_object_dummy_self`) used above. let existential_trait_refs = regular_traits.iter().map(|i| { <del> i.trait_ref().map_bound(|trait_ref| self.trait_ref_to_existential(trait_ref)) </del> <ins> i.trait_ref().map_bound(|trait_ref| trait_ref_to_existential(trait_ref)) </ins> }); let existential_projections = bounds.projection_bounds.iter().map(|(bound, _)| { bound.map_bound(|b| { <del> let trait_ref = self.trait_ref_to_existential(b.projection_ty.trait_ref(tcx)); </del> <ins> let trait_ref = trait_ref_to_existential(b.projection_ty.trait_ref(tcx)); </ins> ty::ExistentialProjection { ty: b.ty, item_def_id: b.projection_ty.item_def_id,

Discussion:
The following code panics the compiler:
backtrace: <details</details
~Likely diagnostic related :-/~ Disregard that.
Slightly reduced: can also be , but I though this will remove one more warning, so it's worth using here ^^
triage: P-medium. removing nomination label. reasoning: you get the feature flag diagnostic, including the span of the offending code and the suggestion of what to write. So this is reasonable for users to deal with, even with the ICE. (as opposed to cases where the ICE occurs without any useful output for the user.)
Change:
size is bigger than largest supported object" ); } <del> Ok((Size::from_bytes(size), Align::from_bytes(align).unwrap())) </del> <ins> Ok((Size::from_bytes(size), align)) </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. --<!-- 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. --: <!-- 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 --
must not be a power of two to work (e.g. 3, 5, 7, 9, 10, 11, ...). seems to be a lower bound, but I'm not entirely sure. Doesn't panic with anything below these values. Regression in cc
We need to report a proper ub error in for the unwrap on the alignment. Basically do the same thing as if the result of Align::from_bytes is Err. cc
agreed, that's the right fix.
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
Change:
initializer_span, else_block, visibility_scope, <ins> *remainder_scope, </ins> remainder_span, pattern, )

Discussion:
results in I am not sure if this issue exists only in combination with impl Trait of if it can be triggered in some other ways as well, haven't managed to get this bug some other way. cc do you know whether this behavior is known already?
The bug is not known to me. cc who has improved the borrow checking behavior. The suggestion is also weird.
The let-else actually desugars to this if-let: And you . However the suggestion actually makes sense for if-let, because putting a semicolon afterwards does indeed fix it. The suggestion is wrong for the let-else because let-else's desugaring is always in tail position in its enclosing block, any statements thereafter get moved into the if-branch and so no amount of semicolons can take the desugaring out of tail position.
Also note that the old desugaring, which was , does not suffer this particular problem because the temporary has a name and lives outside the tail position expression. That way there is no ordering problem with the ends of x's and the unnamed temporary's lifetimes. So a few things: a named temporary like that is a good suggestion to make instead for let-else, and potentially for if-let as well. presence or absence of a semicolon on a tail position expression of type () having that much significance is pretty bad. Arguably it should not be significant whatsoever. is being a bit obtuse. It isn't explained very well even for the if-let version why the unnamed temporary is still alive when x is being dropped. Conceptually I think borrowck is trying to say that the real implicit return expression is actually that empty space inside the braces of type (). I don't know. if it did explain better, is there a technical reason why borrowck can't figure out that it could simply drop the unnamed temporary first? Because that would be ideal.
Could we just wrap the in the let-else desugaring with a ?
Well isn't that convenient! Yeah, I suppose we could.
I've just tried this, and it also suffers the same thing did, with the unreachable code warnings when the desugaring ends up with a return in both branches. It is probably complaining about the DropTemps expression itself being unreachable.

We can't slap an on it lest it ignore all unreachable code inside, but I think we can disable the emission of such warnings on any DropTemps in typeck's . Right? (Edit, maybe instead in , because this DropTemps will rarely if ever be such that typeck could warn about it.) Example warning:
Ah cool, turned out to be pretty easy.
This compiles successfully as of , which includes . So I'd say it's fixed, but it needs a test before the issue can be closed. includes a test for this, but it's not merged and probably not going to be. The other test in that PR also looks interesting.
Change:
|                         -^ |                         || |                         |not allowed in type signatures <del> |                         help: replace with the correct return type: `&'static &'static usize` </del> <ins> |                         help: replace with the correct return type: `&&usize` </ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/typeck_type_placeholder_item.rs:53:52

Discussion:
The code Emits this diagnostic, which is wrong in this case. It should say cc: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Cannot reproduce: the code snippet as given produces on stable 1.78.0
Did you mean to write this code snippet instead?
Ooops yes :sweat_smile:, edited
claim
Change:
<ins> // compile-flags: --edition 2018 fn foo() -> Result<(), ()> { Ok(try!()); //~ ERROR use of deprecated `try` macro Ok(try!(Ok(()))) //~ ERROR use of deprecated `try` macro } fn main() { let _ = foo(); } </ins>

Discussion:
Old documentation and blogposts will never be updated to not talk about the macro. is It should provide structured suggestions to either use or : This request is similar in spirit to and feels like a subset of . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Would it be fine if I modified and check if the keyword is used, or is there another way to tackle this issue
Change:
pub nodejs: Option<PathBuf>, pub gdb: Option<PathBuf>, pub python: Option<PathBuf>, <ins> pub configure_args: Vec<String>, </ins> } /// Per-target configuration stored in the global configuration structure.

Discussion:
The process of creating the tarballs doesn't include .gitignore files from src/vendor. This results in a missmatched hash failure when building with vendoring enabled. Hoping to switch to rustbuild with the next rust release! FYI: I'd be happy with the vendoring happening during the create tarball process, having enormous vendoring commits in the git history is ugly... !
Needs to be fixed for 1.15.
cc
Seems like the vendoring process should include a sanity check that the vendored sources hash correctly.
Fixed in
Things move fast around here. Awesome thanks!
Change:
fn fold_item(&mut self, i: Item) -> Option<Item> { if let clean::ImplItem(ref imp) = i.inner { if let Some(did) = imp.for_.def_id() { <del> if did.is_local() && !self.retained.contains(&did) { </del> <ins> if did.is_local() && !imp.for_.is_generic() && !self.retained.contains(&did) { </ins> return None; } }

Discussion:
has the implementation which is It is however , so rustdoc does the correct thing after doc inlining. This bug with blanket impls shows up in user's crates, ; for example the trait in itertools does not have its blanket impl visible in the docs.
It regressed on nightly, it also disappeard from the libstd page.
The regression is not due to specialization, see e.g. vs which does not use specialization. Regression is also visible on beta btw.
hmm, is this bug affecting me? , corresponding
Yes, it's the same bug.
thanks. a bit confusing, since that impl is the whole point of my crate :smile:
The regression was already fixed in
Change:
source: SelfSource<'tcx>, valid_out_of_scope_traits: Vec<DefId>, unsatisfied_predicates: &[(ty::Predicate<'tcx>, Option<ty::Predicate<'tcx>>)], <ins> unsatisfied_bounds: bool, </ins> ) { let mut alt_rcvr_sugg = false; <del> if let SelfSource::MethodCall(rcvr) = source { </del> <ins> if let (SelfSource::MethodCall(rcvr), false) = (source, unsatisfied_bounds) { </ins> debug!(?span, ?item_name, ?rcvr_ty, ?rcvr); let skippable = [ self.tcx.lang_items().clone_trait(),

Discussion:
Given the following code (): The output on is: <details<summaryLong diagnostic</summary</details, , , and are suggested three times each: once for , once for , and once for . I'm not sure if this is a problem, but this seems incredibly verbose to me. Note that the output on stable 1.51 and beta 1.52 is different:
My mistake, each repetition is actually different in that two suggest taking a reference to : This still seems like a fairly massive diagnostic, though. I've updated the original post in light of this. Feel free to close if a diagnostic of this size is fine here.
cc
Might be a duplicate of , or at least fixed by the same PR that fixed it
Even if it was considered reasonable to suggest each and every possible type combination, there is no pressing reason for it to generate the intervening lines as well: rustc is a compiler, not a can of spam. This remains unpatched on nightly, and is thus a stable-to-beta diagnostic regression.
AFAICT, this is not present on beta, and is only present on nightly, so it's a stable-to-nightly regression. Please correct me if I misunderstood!
searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24 regressed nightly: nightly-2021-04-09 searched commits: from to regressed commit: That is: so it’s . I guess has already been mentioned. label D-verbose
Yes, yes, I introduced this regression. Mea culpa, everybody. In my defense I keep flip-flopping between being too restrictive and too permissive for new suggestions and someone always ends up getting the short end of the stick. This week, I'm leaning towards "too permissive" and if the suggestion triggers too often, then detect the cases and make it more constrained, because the alternative is that the suggestion isn't shown when it could, and we'll never find out. This is IMO better, as long as regressions are caught in nightly, like it was in this case.&lt;/rantAnyways, fixes this.
Assigning and removing .
This now affects 1.53.0 beta. Updating the labels accordingly.
Still needs to be backported.
the beta backport for patch was approved, can this now be closed?

I think we should wait until it actually lands onto beta
This was merged in beta already, right?
Ah, so it was.
Change:
if !line.starts_with(key) { continue } <del> if line.starts_with(&format!("{}['{}']", key, krate)) { </del> <ins> if line.starts_with(&format!(r#"{}["{}"]"#, key, krate)) { </ins> continue } ret.push(line.to_string());

Discussion:
E.g. doesn't show the crate.
ccing myself, will have a look at this in the next week or so.
cc me
Triage: searching for libc doesn't show libc.
Hmm, I deliberately removed the search-index entry in because it was .
Change:
<ins> trait Hello {} struct Foo<'a, T: ?Sized>(&'a T); impl<'a, T: ?Sized> Hello for Foo<'a, &'a T> where Foo<'a, T>: Hello {} impl Hello for Foo<'static, i32> {} fn hello<T: ?Sized + Hello>() {} fn main() { hello(); //~^ ERROR type annotations needed } </ins>

Discussion:
<!-- 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 have a full repro in , but the short version is, it seems like some cases of code that look_ like an omitted type should be inferrable: while certain dependencies, leading to , are in the compile pathway (I could only get it to reproduce via a weird dependency chain via a workspace and a couple of public crates), can lead to an overflow: If the dependency chain is altered in any way that I could divine, the expected error is output: <!-- 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. --I've reproduced this bug both in and in . :
Bisects to nightly-2023-10-07. In nightly-2023-10-06, we get "the expected error" shown above.
Looks like , because reproduces the issue, but the previous commit on master () does not.
Minimal:
I'll put up a fix in a sec
WG-prioritization assigning priority (). label -I-prioritize +P-medium