jiebi/CodeConvo huggingface dataset:
Change:
traits.entry(trait_ref).or_default().extend(proj_ty); } <ins> fn pretty_print_inherent_projection( self, alias_ty: &ty::AliasTy<'tcx>, ) -> Result<Self::Path, Self::Error> { let def_key = self.tcx().def_key(alias_ty.def_id); self.path_generic_args( |cx| { cx.path_append( |cx| cx.path_qualified(alias_ty.self_ty(), None), &def_key.disambiguated_data, ) }, &alias_ty.substs[1..], ) } </ins> fn ty_infer_name(&self, _: ty::TyVid) -> Option<Symbol> { None }

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 --
regression in cc
claim
another one `

<!-- 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 --
Regression in cc
Thanks :) claim
Change:
}); } <del> fn unnecessary_stable_feature_lint(tcx: TyCtxt<'_>, span: Span, feature: Symbol, since: Symbol) { </del> <ins> fn unnecessary_stable_feature_lint( tcx: TyCtxt<'_>, span: Span, feature: Symbol, mut since: Symbol, ) { if since.as_str() == VERSION_" { since = rust_version_symbol(); } </ins> tcx.struct_span_lint_hir(lint::builtin::STABLE_FEATURES, hir::CRATE_HIR_ID, span, |lint| { lint.build(&format!( "the feature `{feature}` has been stable since {since} and no longer requires an 

Discussion:
with rustc master looks like the stabilisation version is borked? :sweat_smile: cc
Hm, it actually says it like this in the code :D
This is correct, but not ideal: https://rustc-dev- cc maybe we want to special case this in the diagnostics
Yeah seems I've missed correcting that lint. For GATs, the stabilization version will be adjusted very soon, in the coming days, as we are close to the release cycle. But this needs to be fixed for future stabilizations as well. Working on a PR. label bug
Error: Label bug can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Yeah it warns correctly for lib features so only lang features are affected:
PR filed:
Change:
<ins> error[E0380]: auto traits cannot have associated items --> $DIR/assoc-ty.rs:10:10 | LL | auto trait Trait { |            ----- auto traits cannot have associated items LL | LL |     type Output; |     -----^^^^^^- help: remove these associated items error[E0658]: auto traits are experimental and possibly buggy --> $DIR/assoc-ty.rs:8:1 | LL | / auto trait Trait { LL | | LL | |     type Output; LL | | LL | | } | |_^ | = note: see issue #13231 <https://github.com/rust-lang/rust/issues/13231> for more information = help: add `#![feature(auto_traits)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error[E0308]: mismatched types --> $DIR/assoc-ty.rs:15:36 | LL |     let _: <() as Trait>::Output = (); |            ---------------------   ^^ types differ |            | |            expected due to this | = note: expected associated type `<() as Trait>::Output` found unit type `()` = help: consider constraining the associated type `<() as Trait>::Output` to `()` or calling a method that returns `<() as Trait>::Output` = note: for more information, visit https://doc.rust-lang.org/book/ch19-03-advanced-traits.html error: aborting due to 3 previous errors Some errors have detailed explanations: E0308, E0380, E0658. For more information about an error, try `rustc --explain E0308`. </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<strongICE location label +A-auto-traits +F-unboxed_closures
Minimized: <details<summaryError output</summary</details label -F-unboxedclosures +F-autotraits
Regression in nightly-2023-06-18 (...)
probably just another duplicate of

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected builtin trait with associated type: <u16 as Z<'b, u16', 'error: internal compiler error: unexpected builtin trait with associated type: <u16 as Z<'b, u16' 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
Regression in nightly-2023-06-18 Regression in / ping
The depth of the stack at the ICE depends on the recursion limit. Add and it still ICEs, but with only 8 repeated stack portions.
Simplified to use only locally defined traits, not use a lifetime parameter, and hit fewer errors: Oddly enough, this variant hits the same ICE but without such a deep stack.
You can replace the bound with a lifetime bound to reproduce too, such as .
Change:
/// Helper for pushing to `self.suggestions`, if available (not disable). fn push_suggestion(&mut self, suggestion: CodeSuggestion) { <ins> for subst in &suggestion.substitutions { for part in &subst.parts { let span = part.span; let call_site = span.ctxt().outer_expn_data().call_site; if span.in_derive_expansion() && span.overlaps_or_adjacent(call_site) { // Ignore if spans is from derive macro. return; } } } </ins> if let Ok(suggestions) = &mut self.suggestions { suggestions.push(suggestion); }

Discussion:
No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Short code to reproduce the issue.
Change:
); } } else { <ins> let tcx = self.tcx(); </ins> if let ty::ConstKind::Unevaluated(def_id, substs, promoted) = constant.literal.val { if let Some(promoted) = promoted { let check_err = |verifier: &mut TypeVerifier<'a, 'b, 'tcx>,

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 tried : I expected to see this: Instead, happens undefined behavior. Program successfully compiles in the Rust but fails to compile in (thats what I want).
Regressed in , likely cc
Visited in the compiler team triage meeting. It would be good to look into closing this ASAP. do you think you'll have time to investigate? If not, I'd want to find someone else.
We've assigned this speculatively to -- if you think you won't be able to investigate promptly, though, feel free to unassign and ping t-compiler for reassignment,
I expected the behavior to match that of this example (which still errors): I wonder if the gets erased somehow. Maybe an "user type annotation" is required on the from a , to give it a lifetime'd type?
Change:
<ins> // run-rustfix pub trait MyTrait { type T; fn bar(self) -> Self::T; } pub fn foo<A: MyTrait<T = B>, B>(a: A) -> B { return a.bar(); //~ ERROR mismatched types } fn main() {} </ins>

Discussion:
When a type parameter is expected, but an unconstrained associated type is found rustc suggests a syntactically incorrect fix with a misleading help message about trait bounds instead of associated type constraints. No response
Change:
pub for_param_list_exists: bool, } <ins> pub(crate) struct FnTraitMissingParen { pub span: Span, pub machine_applicable: bool, } impl AddToDiagnostic for FnTraitMissingParen { fn add_to_diagnostic_with<F>(self, diag: &mut rustc_errors::Diagnostic, _: F) where F: Fn( &mut rustc_errors::Diagnostic, rustc_errors::SubdiagnosticMessage, ) -> rustc_errors::SubdiagnosticMessage, { diag.span_label(self.span, crate::fluent_generated::parse_fn_trait_missing_paren); let applicability = if self.machine_applicable { Applicability::MachineApplicable } else { Applicability::MaybeIncorrect }; diag.span_suggestion_short( self.span.shrink_to_hi(), crate::fluent_generated::parse_add_paren, "()", applicability, ); } } </ins> #[derive(Diagnostic)] #[diag(parse_unexpected_if_with_if)] pub(crate) struct UnexpectedIfWithIf(

Discussion:
It feels like rustc should be able to determine that a trait followed by a is a -family trait bound and be able to suggest this behavior. If that is too general it could just check for , , . Very similar is if parenthesis are missing from regular declarations: Also happens on nightly according to Rust Playground. I'd like to try my hand at implementing this diagnostic, but I'll likely need a little bit of locational guidance. A naive code search show that the message is emitted by this code is the parser diagnostics, but I'm not sure if the adjustment would need to be made within that or from where it is invoked in this case. Edit: Updated to use the wording "-family trait bounds" rather than "HRTBs"._
Where this function is invoked. Try looking for the code that parses .
If you end up writing a fix, note that those trait bounds are usually called -family trait bounds, not “HRTBs”. The latter would require at least one higher-rank parameter to be involved (e.g. ).
It seems this diagnostic contextually comes from which does this token search by . As corroboration it also seems that declaring a regular without parenthesis causes a similar if more contextually understandable error: I naively think that the adjustment point should probably be rather than ... However I don't understand how the output gets multiple possibilities e.g. and in this output: or the whole list of Since it's only calling with from ... I guess this requires catching the result in and handling this result type somehow?
Any time you call , it stashes the token type you tried probing for and it'll present that in a list whenever you get to . (Or something like that).
Anyways, it shouldn't matter -- in the caller to (when parsing ), you could add a check for before calling and handle the token specifically.
Just chiming in to mention: in any parser change you make here make sure you don't start accepting new code and add tests for all combinations you can think of.
Change:
ty::Float(float_ty) => output.push_str(float_ty.name_str()), ty::Foreign(def_id) => push_item_name(tcx, def_id, qualified, output), ty::Adt(def, substs) => { <del> let ty_and_layout = tcx.layout_of(ParamEnv::reveal_all().and(t)).expect("layout error"); </del> <ins> // `layout_for_cpp_like_fallback` will be `Some` if we want to use the fallback encoding. let layout_for_cpp_like_fallback = if cpp_like_debuginfo && def.is_enum() { match tcx.layout_of(ParamEnv::reveal_all().and(t)) { Ok(layout) => { if !wants_c_like_enum_debuginfo(layout) { Some(layout) } else { // This is a C-like enum so we don't want to use the fallback encoding // for the name. None } } Err(e) => { // Computing the layout can still fail here, e.g. if the target architecture // cannot represent the type. See https://github.com/rust-lang/rust/issues/94961. tcx.sess.fatal(&format!("{}", e)); } } } else { // We are not emitting cpp-like debuginfo or this isn't even an enum. None }; </ins> <del> if def.is_enum() && cpp_like_debuginfo && !wants_c_like_enum_debuginfo(ty_and_layout) { </del> <ins> if let Some(ty_and_layout) = layout_for_cpp_like_fallback { </ins> msvc_enum_fallback( tcx, ty_and_layout,

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. --code from glacier <!-- 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. --: with cc <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This would previously just throw an error but not "crash": `
I'll look into it. Thanks for the bug report!
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. #![deny(warnings)] //~ NOTE: lint level defined here use std::thread; //~ ERROR: unused import fn main() {} </ins>

Discussion:
Normally, an unused import: Produces this compiler output: Saying the 'unusedimports' lint is 'on by default'. If you explicitly set that lint to deny: Then the error indicates where the lint was set to 'deny': If you instead change warnings to errors: Then you get this error: Which says 'deny(unusedimports)' is 'on by default'. That is not true. unused_imports is warn by default. This case should point to as the source of the error. Discovered while interpreting all the lint regressions in . cc
I took a shot at this and made a PR. Now your example code for deny(warnings) shows the following:
This was fixed by .
Change:
libc::abort(); } } <del> } else if #[cfg(any(target_os = "macos", target_os = "ios", target_os = "redox"))] { use crate::sys::os::errno; for fd in 0..3 { if libc::fcntl(fd, libc::F_GETFD) == -1 && errno() == libc::EBADF { if libc::open("/dev/null0".as_ptr().cast(), libc::O_RDWR, 0) == -1 { libc::abort(); } } } </del> } } }

Discussion:
polls to the standard file descriptors on startup; if they are closed, it attempts to reopen them to . If  is too low, the polling (or opening) will cause an abort. The could be checked ahead of time. I tried this Docker configuration I expected to see this happen: Successful execution Instead, this happened: Process aborted It most recently worked on: Rust 1.47 Rust 1.48 and forward. modify labels: +regression-from-stable-to-stable -regression-untriaged
Are file descriptors 0-2 open at the time of the abort? Edit, ah, I see this is a limitation of , not of the process being incorrectly spawned. This could be solved by a fallback to calling on individual fds if poll doesn't work.
We're happy to review a patch for this. (E.g. falling back to fstat if poll returns EINVAL.)
Change:
}; let sp = cx.with_def_site_ctxt(sp); <del> let e = match env::var(&var.as_str()) { Err(..) => { </del> <ins> let value = env::var(&var.as_str()).ok().as_deref().map(Symbol::intern); cx.parse_sess.env_depinfo.borrow_mut().insert((Symbol::intern(&var), value)); let e = match value { None => { </ins> let lt = cx.lifetime(sp, Ident::new(kw::StaticLifetime, sp)); cx.expr_path(cx.path_all( sp,

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:
<del> Subproject commit 23549a8c362a403026432f65a6cb398cb10d44b7 </del> <ins> Subproject commit d8e6e4cfcd83d555bd7717ea24224b777ed75773 </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! And nominating for compiler team prioritization.
Change:
&mut values.0, &mut values.1, path1.clone(), <del> sub1, </del> <ins> sub_no_defaults_1, </ins> path2.clone(), &t2, ).is_some()

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:
for pass in passes { let name = pass.name(); <del> let overridden = overridden_passes.iter().rev().find(|(s, _)| s == &*name).map( |(_name, polarity)| { trace!( pass = %name, "{} as requested by flag", if *polarity { "Running" } else { "Not running" }, ); *polarity }, ); if !overridden.unwrap_or_else(|| pass.is_enabled(&tcx.sess)) { </del> <ins> if !should_run_pass(tcx, *pass) { </ins> continue; <del> } </del> <ins> }; </ins> let dump_enabled = pass.is_mir_dump_enabled();

Discussion:
While trying to build a test for , I renamed my test file and it stopped ICEing. I have no idea what's happening here. Create a file with this contents called Then This compiles fine: But this ICEs:
We skip calling by comparing def-path hashes. The def-path hash provides a total order on MIR bodies that respects incremental compilation, and avoids a potentially costly query. OTOH, it depends on the crate name, which is the file name in your example. If you add a somewhere, that should be reproducible.
Setting the crate name would stabilize this for now, but any change to the hash algorithm could cause this test to suddenly pass, even if the compiler regresses in its behavior. Is there a way around that problem?
As someone who has changed the hash algorithm before, a comment in the file that says you might have to fiddle with the crate name to find something where that check works (including a link to this issue) might be enough if there's no other option.
I'm not concerned about the test suddenly failing, I'm concerned about it suddenly passing when it shouldn't.
I can't reproduce the MCVE in your opening comment. However, if I rename the file to then it emits an ICE (which I suspect is the same you reported here, is it? <details</detailsTo summarize: :heavycheckmark: :heavycheckmark: :skull: I'm really puzzled. Any idea? :thinking: EDIT: worth mentioning I'm on the latest nightly:
For testing purposes? Repeat the test a number of times to ensure that it is unlikely that it will pass by an accident.
Yes, that is the ICE in question, and your difficulty in reproducing this underscores the problem here. Any ICE that relies on MIR inlining within a crate (as opposed to inlining a function from another crate) may stop reproducing basically at any time. I believe this is the same reason that bisects to unrelated commits.
Change:
"packed", "static_assert", "thread_local", <ins> "no_debug", </ins> // not used anywhere (!?) but apparently we want to keep them around "comment",

Discussion:
Right now debuginfo can only be turned on or off globally. Sometimes it would be good to be able to exclude only specific functions from debuginfo, especially when they trigger a bug in rustc's or LLVM's debuginfo handling (e.g. ). This way, one would be able to still mostly use debuginfo in the presence of (localized) debuginfo issues.
Change:
<ins> // issue:113951 trait Foo<'x, T> {} trait RefFoo<T> { fn ref_foo(&self); } impl<T> RefFoo<T> for T where for<'a> &'a mut Vec<&'a u32>: Foo<'static, T>, { fn ref_foo(&self) {} } fn coerce_lifetime2() { <i32 as RefFoo<i32>>::ref_foo(unknown); //~^ ERROR cannot find value `unknown` in this scope //~| ERROR the trait bound `for<'a> &'a mut Vec<&'a u32>: Foo<'static, i32>` is not satisfied } fn main() {} </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
Started crashing with Regression in nightly-2022-05-19 commit[0] 2022-05-17: Auto merge of - jsha:rustdoc-search-refactor, r=GuillaumeGomez commit[1] 2022-05-18: Auto merge of - JohnTitor:rollup-7gdt2aw, r=JohnTitor commit[2] 2022-05-18: Auto merge of - Dylan-DPC:rollup-06u9pqn, r=Dylan-DPC commit[3] 2022-05-18: Auto merge of - Kobzol:pgo-pid-in-profile, r=lqd commit[4] 2022-05-18: Auto merge of - michaelwoerister:path-prefix-fixes-2, r=davidtwco commit[5] 2022-05-18: Auto merge of - nbdd0121:const, r=nagisa commit[6] 2022-05-18: Auto merge of - SparrowLii:let, r=michaelwoerister commit[7] 2022-05-18: Auto merge of - b-naber:transition-to-valtrees-pt1, r=oli-obk
WG-prioritization assigning priority (). label -I-prioritize +P-medium -needs-triage