jiebi/CodeConvo huggingface dataset:
Change:
// like implicit `?Sized` or const-param-has-ty predicates. } } <ins> match p.kind { GenericParamKind::Lifetime { .. } => {} GenericParamKind::Type { default, .. } => { if let Some(ty) = default { self.visit_ty(ty); } } GenericParamKind::Const { ty, default } => { self.visit_ty(ty); if let Some(default) = default { self.visit_body(self.tcx.hir().body(default.body)); } } } </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 --
claim
Change:
<ins> fn problematic_function<Space>(material_surface_element: ()) where DefaultAllocator: FiniteElementAllocator<(), Space>, { let _: Point2<f64> = material_surface_element.map_reference_coords().into(); } impl<N, R> Allocator<N, R> for DefaultAllocator where R::Value: DimName, //~ ERROR: `Value` not found for `R` { type Buffer = (); } impl<N> Allocator<N, ()> for DefaultAllocator {} //~^ ERROR: conflicting implementations impl DimName for () {} impl DimName for u32 {} impl<N, D: DimName> From<VectorN<N, D>> for Point<N, D> { fn from(_: VectorN<N, D>) -> Self { todo!() } } impl FiniteElement<u32> for () {} type VectorN<N, D> = Matrix<<DefaultAllocator as Allocator<N, D>>::Buffer>; type Point2<N> = Point<N, u32>; struct DefaultAllocator; struct Matrix<S>(S); struct Point<N, D>(N, D); trait Allocator<Scalar, R> { type Buffer; } trait DimName {} trait FiniteElementAllocator<GeometryDim, NodalDim>: Allocator<f64, ()> + Allocator<f64, NodalDim> { } trait FiniteElement<GeometryDim> { fn map_reference_coords(&self) -> VectorN<f64, GeometryDim> { todo!() } } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead', 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirbuilt] building MIR for [checkunsafety] unsafety-checking [analysis] running analysis passes on this crate --
cc
Change:
"deref-methods-{:#}", type_.print(cx.cache()) ))); <ins> debug!("Adding {} to deref id map", type_.print(cx.cache())); </ins> cx.deref_id_map .borrow_mut() .insert(type_.def_id_full(cx.cache()).unwrap(), id.clone());

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. --Original: Minimized: <!-- 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 --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.
Change:
.predicates .into_iter() { <del> if let ty::PredicateKind::Trait(..) = super_trait.kind().skip_binder() { let normalized_super_trait = normalize_with_depth_to( self, obligation.param_env, obligation.cause.clone(), obligation.recursion_depth + 1, super_trait, &mut nested, ); nested.push(Obligation::new( obligation.cause.clone(), obligation.param_env, normalized_super_trait, )); } </del> <ins> let normalized_super_trait = normalize_with_depth_to( self, obligation.param_env, obligation.cause.clone(), obligation.recursion_depth + 1, super_trait, &mut nested, ); nested.push(Obligation::new( obligation.cause.clone(), obligation.param_env, normalized_super_trait, )); </ins> } let assoc_types: Vec<_> = tcx

Discussion:
Found in () Errors: modify labels: T-compiler, C-bug, A-traits, A-dst, A-associated-items, A-typesystem and please add “I-unsound ”
cc - this looks like it might be related to some of your work.
Assigning as discussed as part of the and removing .
Without the keyword, the function type-checks since Rust 1.0.0. And a function like e.g. leads to reading a bunch of memory and segfaulting on every Rust version, as far as I can tell (at least in debug builds).
To me, this is the same root cause as : we unconditionally say that any type is well-formed and implements without checking the actual where clauses declared on the trait, so you can deduce contradictory things with the help of implied bounds (to be fair, already introduced some checks). Except that I was wrong in my saying that an easy fix for our current limited form of implied bounds would be to just check transitive lifetime requirements. Obviously, example shows that implied bounds for super traits play a role as well.
Change:
filename.to_string().replace(" ", " ") } <ins> // Makefile comments only need escaping newlines and ``. // The result can be unescaped by anything that can unescape `escape_default` and friends. fn escape_dep_env(symbol: Symbol) -> String { let s = symbol.as_str(); let mut escaped = String::with_capacity(s.len()); for c in s.chars() { match c { 'n' => escaped.push_str(r"n"), 'r' => escaped.push_str(r"r"), '' => escaped.push_str(r""), _ => escaped.push(c), } } escaped } </ins> fn write_out_deps( sess: &Session, boxed_resolver: &Steal<Rc<RefCell<BoxedResolver>>>,

Discussion:
This is still in 's build script: But the use site has been moved here: This means that won't be rebuilt when that env var changes. For the record, I haven't seen a bug from this, was just curious where may be used and spotted the mismatch. cc
Found another one: is used in but it's still mentioned by . cc Could we automate ensuring this? e.g. by searching for in tidy.
Yeah, we can try I guess. Not sure :) Maybe the right solution is that Cargo would, other than some whitelist, remove unknown variables from rustc's environment -- and the whitelist can be expanded via the build script env-tracking.
hmm I wonder if abusing the file format (from ) or encoding this extra info in a comment, would be a good idea.
You mean such that if you use we automatically tell Cargo to rebuild on changes? (That's ). But yeah, I think that would be good. Ideally this would be "well-integrated" vs. the current state of everyone having to remember to do it.

(As discussed with on IRC.) Rustc should have an option to obtain a list, as part of building, of every environment variable that was requested via the or macros (tagged accordingly with "required" or "optional"), as well as providing a way to instrument intrinsics like called by scripts. This will make it more feasible to detect (and lint about) the usage of environment variables only set by newer build bits (e.g. Cargo) without an appropriate versioned dependency; for instance, it'd be possible to say "you use the environment variable without a dependency on a version of Cargo that supplies . This would also help people doing reproducible builds to see what environment variables might affect a build. This will never be perfect; it can't capture variables read from native code or from code that goes out of its way to bypass the normal mechanism (e.g. calling .) However, this would still catch many common cases.
Just following up to say that this is an accurate reflection of what we discussed. As said, it's part of a larger goal to detect usage of newer Cargo features on older versions of Cargo and let the user know which version of Cargo they need to upgrade to. For keys in , it's enough to simply keep a list of when a particular key was (since Cargo is the one parsing ). But if Cargo adds an environment variable, we need some compiler help to detect that the environment variable was used from Rust code.
I believe this may be a dupe of
They're related, though I think seems more narrow in scope.
Change:
predicate: pred.to_predicate(infcx.tcx), }; <del> let result = infcx.predicate_must_hold_modulo_regions(&obligation); </del> <ins> let result = infcx.evaluate_obligation_no_overflow(&obligation); </ins> debug!(?result); <del> if result && has_non_region_infer { </del> <ins> if result.must_apply_modulo_regions() && !has_non_region_infer { true } else if result.may_apply() { </ins> // Because of inference "guessing", selection can sometimes claim // to succeed while the success requires a guess. To ensure // this function's result remains infallible, we must confirm

Discussion:
While trying to upgrade rustc to the latest nightly, I stumbled across a Rust compiler panic. Here's a repo that contains a minimum-reproducible test case (well, reasonably compact): From my brief investigation, it appears that adding the combinator causes recent rustc nightly's to panic. I've bisected the recent nightly versions; is the first that starts panicking. Running with builds successfully. To reproduce the bug, just run . Running doesn't panic, though, since it seems to be codegen related. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2023-02-01 to nightly-2023-03-04 regressed nightly: nightly-2023-02-09 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: </detailsRegressed in , cc
I have (a couple of) fixes for this PR, but I really need this minimized :/
WG-prioritization assigning priority (). label -I-prioritize +P-critical +E-needs-mcve
I'll work on minimizing it in the meantime
I've started some work I but it's extremely miserable because of hypers internal highly entangled generic mess
I tried some more and I'm convinced that this ICE here cannot be minimized in a reasonable amount of time. The ICE is very brittle and disappears with seemingly random changes and the codebase is huge and highly generic with many bounds. I'll leave the label here, but I don't recommend anyone working on this (unless you hate fun and want to waste your time).
We don't have a test, but given that we won't get a test from this report, keeping it open doesn't seem useful.
Change:
/// } /// ``` #[lang="deref_mut"] <del> pub trait DerefMut<Sized? Result>: Deref<Result> { </del> <ins> pub trait DerefMut<Sized? Result> for Sized? : Deref<Result> { </ins> /// The method called to mutably dereference a value fn deref_mut<'a>(&'a mut self) -> &'a mut Result; }

Discussion:
This currently is not the case, so you can't impl where is unsized. Note that this is distinct from whether is (it is).
Hmm, yeah I guess at first glance it seems strange that is but is this at least looks like an easy fix to me.
I'm not really sure who to ping on this, maybe I should just make up a pull request and see what happens?
Yeah, probably :)
Yeah, just adding seems fine.
Awesome. I'll put together a pull request now then.
Change:
let result = if let Some(trait_def_id) = tcx.trait_of_item(def.did) { debug!(" => associated item, attempting to find impl in param_env {:#?}", param_env); <del> resolve_associated_item(tcx, def.did, param_env, trait_def_id, substs) </del> <ins> resolve_associated_item( tcx, def.did, param_env, trait_def_id, tcx.normalize_erasing_regions(param_env, substs), ) </ins> } else { let ty = tcx.type_of(def.def_id_for_type_of()); let item_type = tcx.subst_and_normalize_erasing_regions(substs, param_env, ty);

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
label +requires-debug-assertions
Reduced from 205 lines to 56 lines: Error output with :
Change:
match (&t1.sty, &t2.sty) { (&ty::TyAdt(def1, sub1), &ty::TyAdt(def2, sub2)) => { <ins> let sub_no_defaults_1 = self.strip_generic_default_params(def1.did, sub1); let sub_no_defaults_2 = self.strip_generic_default_params(def2.did, sub2); </ins> let mut values = (DiagnosticStyledString::new(), DiagnosticStyledString::new()); let path1 = self.tcx.item_path_str(def1.did.clone()); let path2 = self.tcx.item_path_str(def2.did.clone());

Discussion:
In , adding an parameter to the type, that defaults to induces changes to UI tests that are indicative of something that seemed to need improvement in the compiler, namely that when you have a type , errors should present instead of when they can. It turns out, the compiler does. But not consistently. The following is derived from : () This yields the following errors: See how it prints instead of the (imho) desired , but , not .
This all stems from the fact that in some cases, types are just printed out by formatting the instances, while in other cases, there is manual machinery to highlight parts of the type that handle things, and that doesn't have the default-param elimination that has.
Change:
pub static mut L: u8 = 0; }; <del> // The surrounding item should not accidentally become external </del> fn x() { // CHECK: @M = local_unnamed_addr constant #[no_mangle]

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 couldn't I couldn't produce a single file example, as it seems the ICE is triggered when cross crate compilation is involved; i.e dumping the contents of into does not trigger the ICE. This seems like a regression of the feature as this previously worked on nightly of the 1.50 stable release. : : <!-- 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
While regression itself is related to the introduction of CTFE MIR, it seems this actually never worked correctly, with static ending up duplicated.
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
I can't reproduce with the latest nightly and cargo. Are there any further instructions for reproducing this?
Apologies, forgot to mention you'll need to add Or build for a target that does not have panic unwinding enabled by default.
(discussed in T-compiler meeting. This is an issue on stable, and might get a backport via . Re-opening to investigate details of what worked, what stopped working, what is fixed, and what is still broken.)
In the case reported here, one crate references static from another crate. During mono item collection, based on reachability determines whether it will link to item from an upstream crate or codegen it locally. When decision is made to codegen locally, it is followed by an assertion that optimized MIR is available to do so. In 1.50 static is non-reachable and codegenned locally. In 1.51 and 1.52 static is non-reachable, but the assertion fails since statics no longer use optimized MIR. In nightly, since , the static is reachable and linked to. The change seems safe for backporting to me.
Closing as the .
Change:
<ins> warning: to use a constant of type `WrapEmbedded` in a pattern, `WrapEmbedded` must be annotated with `#[derive(PartialEq, Eq)]` --> $DIR/null-raw-ptr-issue-119270.rs:13:9 | LL |         WRAP_UNSAFE_EMBEDDED => true, |         ^^^^^^^^^^^^^^^^^^^^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #62411 <https://github.com/rust-lang/rust/issues/62411> = note: the traits must be derived, manual `impl`s are not sufficient = note: see https://doc.rust-lang.org/stable/std/marker/trait.StructuralEq.html for details = note: `#[warn(indirect_structural_match)]` on by default warning: 1 warning emitted </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: shouldn't have created a ValTree for const NoDerive', 'error: internal compiler error: shouldn't have created a ValTree for const NoDerive' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [valtreetoconstval] converting type-level constant value to mir constant value [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
Regression in cc
Should be fixed by
label -needs-triage
Change:
LL |     let x = -1.7976931348623159e+308_f64; |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | <del> = note: the literal `1.7976931348623159e+308_f64` does not fit into the type `f64` and will be converted to `std::f64::INFINITY` </del> <ins> = note: the literal `1.7976931348623159e+308_f64` does not fit into the type `f64` and will be converted to `f64::INFINITY` </ins> error: literal out of range for `f64` --> $DIR/lint-type-overflow2.rs:12:14

Discussion:
This program: Produces this output: Note the references to ; these symbols have been superseded by associated consts at (). the error message to suggest the new symbols if any of the other old symbols are contained in any error messages. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
See also .
I am working on this. claim
: I've gone and grepped through for , , etc. and found no accidental uses there. I then grepped for each of the individual symbols listed in RFC 2700 (, , etc.) and didn't notice anything out of place. I also grepped for (as seen in this issue) and found only a hint message for things like etc which only triggers when an item isn't found at all, which won't trigger for any of the new consts. Probably safe to close this once merges.
You are right. I was thinking of cases like this one but this can likely be closed with the merge of that PR. I was operating with an abundance of caution.
Yeah, that's the aforementioned case that only shows up in the event of an error, so (AFAICT) that path won't be taken for the new constants since they resolve successfully.
Change:
fn universe_for(&mut self, debruijn: ty::DebruijnIndex) -> ty::UniverseIndex { let infcx = self.infcx; let index = <del> self.universe_indices.len() - debruijn.as_usize() + self.current_index.as_usize() - 1; </del> <ins> self.universe_indices.len() + self.current_index.as_usize() - debruijn.as_usize() - 1; </ins> let universe = self.universe_indices[index].unwrap_or_else(|| { for i in self.universe_indices.iter_mut().take(index + 1) { *i = i.or_else(|| Some(infcx.create_next_universe()))

Discussion:
The test fails due to an arithmetic overflow when debug assertions are enabled. The offending code likely intends to use the explicit wrapping math methods, as the test does pass with the overflow. The test was implemented in <details<summaryBacktrace</summary<p</p</details
The overflowing code is To me, it actually seems like the overflow might be a bug. it looks like you this code. Is it incorrect for it to be overflowing?
This is introduced in with guards like near call-site. So I suppose just swapping the order should be sufficient?
Overflowing here is a bug. Given that we haven't seen an index out of bound panics on like 562, I would guess that the actual logic here is correct (so, we underflow, then overflow). I do want to prove to myself that again (and put it in a comment).
If it is really intended then should be used.
Oh, I think I ran into this as well and thought it was due to a local change I had made violating an invariant.
Duplicate of ?
no, that issue is in diagnostics, while this one is in trait resolution. I'll try to get to the diagnostics issue next week
label -I-prioritize
Ah my bad, thanks. I think I've been running in to both issues and conflating them.