jiebi/CodeConvo huggingface dataset:
Code change:
{ value.fold_with(&mut RegionFolder::new(self, &mut f)) } <del> pub fn super_fold_regions<T>( self, value: T, mut f: impl FnMut(ty::Region<'tcx>, ty::DebruijnIndex) -> ty::Region<'tcx>, ) -> T where T: TypeSuperFoldable<TyCtxt<'tcx>>, { value.super_fold_with(&mut RegionFolder::new(self, &mut f)) } </del> } /// Folds over the substructure of a type, visiting its component

Related discussion:
text: <!-- 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
probably Regression in searched nightlies: from nightly-2023-02-15 to nightly-2023-03-16 regressed nightly: nightly-2023-02-20 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
It's actually
Or at least, the logic broke because of , so the ICE message probably changed in that PR from some other message, to this one in the title.
label +S-bug-has-mcve
Code change:
use rustc_target::abi::FieldIdx; use rustc_target::spec::abi::Abi::RustIntrinsic; use rustc_trait_selection::infer::InferCtxtExt; <ins> use rustc_trait_selection::traits::error_reporting::TypeErrCtxtExt; use rustc_trait_selection::traits::ObligationCtxt; </ins> use rustc_trait_selection::traits::{self, ObligationCauseCode}; impl<'a, 'tcx> FnCtxt<'a, 'tcx> {

Related discussion:
text: I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim
Code change:
} if self.config.rust_remap_debuginfo { <del> // FIXME: handle vendored sources let registry_src = t!(home::cargo_home()).join("registry").join("src"); </del> let mut env_var = OsString::new(); <del> for entry in t!(std::fs::read_dir(registry_src)) { if !env_var.is_empty() { env_var.push("t"); } env_var.push(t!(entry).path()); </del> <ins> if self.config.vendor { let vendor = self.build.src.join("vendor"); env_var.push(vendor); </ins> env_var.push("=/rust/deps"); <ins> } else { let registry_src = t!(home::cargo_home()).join("registry").join("src"); for entry in t!(std::fs::read_dir(registry_src)) { if !env_var.is_empty() { env_var.push("t"); } env_var.push(t!(entry).path()); env_var.push("=/rust/deps"); } </ins> } cargo.env("RUSTC_CARGO_REGISTRY_SRC_TO_REMAP", env_var); }

Related discussion:
text: this is my attempt to bootstrap rust-1.75.0 beta, which fails with this beauty: this is my command: I can workaround this by reverting can you please have a look at this error and the backtrace? I don't get why this error comes up. Thanks
this is my
The fixme here seems to be the issue: As workaround you can try to run before the build. cc
I'm compiling offline, from the beta src tarball.
I'm aware. It seems that there is a bug when using vendored sources in combination with remap-debuginfo. Creating the directory should help even if it is kept empty.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Well, the cargo eclass is already exporting CARGOHOME env var, and a CARGOREGISTRY_DIR as well, and I'm doubtfull about the package manager allowing x.py to escape it's sandbox. Neverthelss, I'll try your suggestion when I'm back home on the machine.
If you have set the directory you need to create is .
for your information only
Code change:
<ins> #![u={static N;}] fn main() {} </ins>

Related discussion:
text: <!-- 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
I suspect this is related to cc
tests/ui/suggestions/unnamable-
Very likely. I'll take a look soon.
For the record: it was that caused this.
Code change:
<ins> // Regression test for #61311 // We would ICE after failing to normalize `Self::Proj` in the `impl` below. // compile-pass pub struct Unit; trait Obj {} trait Bound {} impl Bound for Unit {} pub trait HasProj { type Proj; } impl<T> HasProj for T { type Proj = Unit; } trait HasProjFn { type Proj; fn the_fn(_: Self::Proj); } impl HasProjFn for Unit where Box<dyn Obj + 'static>: HasProj, <Box<dyn Obj + 'static> as HasProj>::Proj: Bound, { type Proj = Unit; fn the_fn(_: Self::Proj) {} } fn main() {} </ins>

Related discussion:
text: Found as a byproduct of work on backtrace: Compiles on stable 1.35.0.
triage: Looks like matthewjasper is on top of this. Marking P-high just so I don't have to think about it further right now. Removing nomination tag.
Code change:
<ins> // Regression test for #61311 // We would ICE after failing to normalize `Self::Proj` in the `impl` below. // compile-pass pub struct Unit; trait Obj {} trait Bound {} impl Bound for Unit {} pub trait HasProj { type Proj; } impl<T> HasProj for T { type Proj = Unit; } trait HasProjFn { type Proj; fn the_fn(_: Self::Proj); } impl HasProjFn for Unit where Box<dyn Obj + 'static>: HasProj, <Box<dyn Obj + 'static> as HasProj>::Proj: Bound, { type Proj = Unit; fn the_fn(_: Self::Proj) {} } fn main() {} </ins>

Related discussion:
text: Happens on stable 1.34.2, 1.35.0 and current nightly (2019-05-28). . Results in:
Reduced:
Compiles fine on 1.34.0; haven't tested 1.34.1.
both my repro and your reduced one do ICE on (and ) for me, can you verify that again?
Happens all the way back to 1.30.0 (with ) for me, as long as is passed to rustc.
Ah of course! is needed for NLL on older versions... :) I forgot that godbolt doesn't have that by default.
Code change:
'u{2004}', 'u{2005}', 'u{2006}', 'u{2007}', 'u{2008}', 'u{2009}', 'u{200A}', 'u{2028}', 'u{2029}', 'u{202F}', 'u{205F}', 'u{3000}']; <del> for c in &chars { let ws = c.is_whitespace(); println!("{} {}" , c , ws); } </del> <ins> for c in &chars { let ws = c.is_whitespace(); println!("{} {}", c, ws); } </ins> }

Related discussion:
text: proc-macro derive panicked All of the 62 regressions are due to old versions of having an assert expecting instead of . So this is again a consequence of whitespace changes in pretty-printing (). I think we should be able to fix this by special casing the comma token during token stream pretty-printing and not printing the space before it.
Fixed in
Just FYI, we discussed this in the meeting. We felt like the action here was appropriate -- while in general we do not guarantee stability of pretty printing, it makes sense to be judicious, and in this particular case not having a leading space before just looks better anyway.
Code change:
AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY) condition: and(succeeded(), or(eq(variables.DEPLOY, '1'), eq(variables.DEPLOY_ALT, '1'))) displayName: Upload artifacts <ins> # Upload CPU usage statistics that we've been gathering this whole time. Always # execute this step in case we want to inspect failed builds, but don't let # errors here ever fail the build since this is just informational. - bash: aws s3 cp --acl public-read cpu-usage.csv s3://$DEPLOY_BUCKET/rustc-builds/$BUILD_SOURCEVERSION/cpu-$SYSTEM_JOBNAME.csv env: AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY) condition: contains(variables, 'AWS_SECRET_ACCESS_KEY') continueOnError: true displayName: Upload CPU usage statistics </ins>

Related discussion:
text: One of the easiest ways to make CI faster is to make things parallel and simply use the hardware we have available to us. Unfortunately though we don't have a lot of data about how parallel our build is. Are there steps we think are parallel but actually aren't? Are we pegged to one core for long durations when there's other work we could be doing? The general idea here is that we'd spin up a daemon at the very start of the build which would sample CPU utilization every so often. This daemon would then update a file that's either displayed or uploaded at the end of the build. Hopefully we could then use these logs to get a better view into how the builders are working during the build, diagnose non-parallel portions of the build, and implement fixes to use all the cpus we've got. cc
On Windows this can be done by taking advantage of job objects. If the entire build is wrapped in a job object then we can call with to get a bunch of useful data.
I made script that will print output into the travis log every 30 seconds , . Some findings: Cloning submodules jemalloc, libcompilerbuildtins and liblibc alone takes 30 seconds. While building bootstrap, compiling serdederive, serdejson and bootstrap crates seems to take 30 seconds (total build time: 47 seconds). stage0: Compiling tidy crate seems to take around 30 seconds. Compiling rustcerrors takes at least 2 minutes, only one codegen-unit is used Compiling syntaxext takes 9 minutes, only one CGU used stage0 codegen artifacts: Compiling rustcllvm takes 1,5 minutes, one CGU During stage1, rustcerrors and syntaxext builds are approximately as slow as during stage0, rustc_plugins 2 minutes, one CGU. stage2: rustdoc took 2 minutes to build, one CGU compiletest suite=run-make mode=run-make: It looks like there is a single test that takes around 3 minutes to complete and has no parallelization. Testing alloc stage1: building liballoc takes around a minute Testing syntax stage1: building syntax takes 1.5 minutes, one CGU Notes: When the load average dropped towards 1, I assumed only one codegen unit was active.
Code change:
AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY) condition: and(succeeded(), or(eq(variables.DEPLOY, '1'), eq(variables.DEPLOY_ALT, '1'))) displayName: Upload artifacts <ins> # Upload CPU usage statistics that we've been gathering this whole time. Always # execute this step in case we want to inspect failed builds, but don't let # errors here ever fail the build since this is just informational. - bash: aws s3 cp --acl public-read cpu-usage.csv s3://$DEPLOY_BUCKET/rustc-builds/$BUILD_SOURCEVERSION/cpu-$SYSTEM_JOBNAME.csv env: AWS_SECRET_ACCESS_KEY: $(AWS_SECRET_ACCESS_KEY) condition: contains(variables, 'AWS_SECRET_ACCESS_KEY') continueOnError: true displayName: Upload CPU usage statistics </ins>

Related discussion:
text: The script was only applied to the default pullrequest travis-ci configuration.
As shown in , the CPUs assigned to each job may have some performance difference: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz The clock-rate 2.4 GHz vs 2.5 GHz shouldn't make any noticeable difference though (this would at most slow down by 7.2 minutes out of 3 hours if everything is CPU-bound). It is not enough to explain the timeout in .
I was working on recently for this where it periodically prints out the CPU usage as a percentage for the whole system (aka 1 core on a 4 core machine is 25%). I only got Linux/OSX working though and was unable to figure out a good way to do it on Windows. My thinking for how we'd do this is probably download a binary near the beginning of the build (or set up some script). We'd then run just before we run . That way we could correlate the two timestamps of each log (the main log and the to similar moments in time. Initially I was also thinking we'd just at the end of the build and scrape it later if need be.
Code change:
<ins> // Regression test for issue #130142 // Checks that we emit no warnings when a lint's level // is overridden by an expect or allow attr on a Stmt node //@ check-pass #[must_use] pub fn must_use_result() -> i32 { 42 } fn main() { #[expect(unused_must_use)] must_use_result(); #[allow(unused_must_use)] must_use_result(); } </ins>

Related discussion:
text: I tried this code: I expected to catch lint and suppress it, as it should. Instead, compiler issues a diagnostic both about unused value and unfulfilled lint expectation: It does work as expected though if is applied to function. I used the latest stable (Rust 1.81), but it is reproducible both on latest beta (2024-09-04 ) and latest nightly (2024-09-05 ). labels: +F-lintreasons, +A-diagnostics <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This issue is not limited to just . Others attrs like or don't work either. For instance, the following variant of the reproducer with replaced with emits the warning even though it shouldn't: Playground: This broken behaviour goes as far back as at least 2021 (couldn't build and test earlier rustc) We emit the lint on the HIR node corresponding to . However, the or levels, which are supposed to override the default level of the lint, are associated with or bound to the node underlying the as shown in the figure below: The end result is that the lint's level is never knocked down to or since when searching for levels we start from the node on which the lint is triggered and go up the chain of parents. So in this case we look for the level on and then on the and so on. We never look for it on the where the levels actually exist. As it happens in the lowered HIR does have the / attrs for both the node and its child node. However when adding the levels in the we do not add anything for the node as shown here (note the comment): If were to add the level for as well the issue will go away. However, if we do that we will still have one problem in the case of which is that we will end up with two expectations and the one on the will not be fullfilled and hence we will still see a warning about unfulfilled expectation. To prevent that I think we should take the following approach: when an attr like or etc.
Code change:
<ins> // Regression test for issue #130142 // Checks that we emit no warnings when a lint's level // is overridden by an expect or allow attr on a Stmt node //@ check-pass #[must_use] pub fn must_use_result() -> i32 { 42 } fn main() { #[expect(unused_must_use)] must_use_result(); #[allow(unused_must_use)] must_use_result(); } </ins>

Related discussion:
text: are present for more than one HIR node in the and if one node is the (direct or indirect) parent of the other node, then add the level only_ for parent node. This will take care of any lints on the child (since we always walk up the HIR hierachy as mentioned earlier) as well as the parent and it will not cause any warnings about missed expectations. I am new to this area so if someone can review this idea or suggest alternatives that will be great. since you seemed to have worked in this area recently, can you please weigh in?
Your investigation is accurate, and the fix is simple: visit the statement node when building lint levels. Do you mind making such a pr ? I don't think we need any special adjustment for cases, duplicated attributes are already taken into account, but a test won't hurt.
Thanks . Yes, I'll put together a PR. My only concern is if all we do is add the level at , although it will work perfectly for , etc., in the case of we will end up with an unfulfilled expectation on the node which will appear to the user as a warning. But anyway let me have a go and see what happens.
Opened draft PR that adds the lint on . It does suffer from the extra warning problem.
Code change:
} let feed_visibility = |this: &mut Self, def_id| { <del> let vis = this.r.tcx.visibility(def_id).expect_local(); </del> <ins> let vis = this.r.tcx.visibility(def_id); let vis = if vis.is_visible_locally() { vis.expect_local() } else { this.r.dcx().span_delayed_bug( span, "error should be emitted when an unexpected trait item is used", ); rustc_middle::ty::Visibility::Public }; </ins> this.r.feed_visibility(this.r.local_def_id(id), vis); };

Related discussion:
text: <!-- 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. --the minimal triggering case seems to impl a trait that isn't visible from the location it ends up. edit: this turns out not to require macros at all. <!-- 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. --: This also occurs in nightly (), but not in stable (which provides the correct complaint that is not publicly re-exported) <!-- 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 --
searched nightlies: from nightly-2023-11-11 to nightly-2023-12-28 regressed nightly: nightly-2023-12-19 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
0x7f6adfe7f645 - core::panicking::panic fmt::hcc at /rustc/ /library/core 72:14 180 x - <rustc resolve[]::late ::LateResolutionVisitor as rustcast[]::visit::Visitor::visititem 19: 0x7f6adee2d7ff - <rustcresolve[]::Resolver::resolvecrate ::{closure} 20: 0x7f6adee2ad1a - <rustcresolve[]::Resolver::resolvecrate 21: 0x7f6adeeb6d72 - rustcinterface[]::passes::resolverforlowering 22: 0x7f6adeeb5e2b - rustcqueryimpl[]::plumbing::rustbeginshortbacktrace::<rustcqueryimpl[]::queryimpl::resolverforlowering::dynamicquery::{closure}::{closure},
Code change:
} let feed_visibility = |this: &mut Self, def_id| { <del> let vis = this.r.tcx.visibility(def_id).expect_local(); </del> <ins> let vis = this.r.tcx.visibility(def_id); let vis = if vis.is_visible_locally() { vis.expect_local() } else { this.r.dcx().span_delayed_bug( span, "error should be emitted when an unexpected trait item is used", ); rustc_middle::ty::Visibility::Public }; </ins> this.r.feed_visibility(this.r.local_def_id(id), vis); };

Related discussion:
text: rustcmiddle[]::query::erase::Erased<[u8; 8usize]23: 0x7f6adef1f8ec - rustcquerysystem[]: :query::plumbing::tryexecutequery::<rustcquery impl[]::DynamicConfig<rustcquerysystem[]::query::caches::SingleCache<rustcmiddle[]::query::erase::Erased<[u8; 8usize], false, false, false, rustcqueryimpl[]::plumbing::QueryCtxt, true24: 0x7f6adef1eff3 - rustcqueryimpl[]::queryimpl::resolverforlowering::getqueryincr::rustendshortbacktrace 25: 0x7f6aded0bab3 - rustcinterface[]::interface::runcompiler::<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure} 26: 0x7f6adee3b25b - std[]::syscommon::backtrace::rustbeginshortbacktrace::<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed27: 0x7f6adee3b0b9 - <<std[]::thread::Builder::spawnunchecked<rustcinterface[]::util::runinthreadwithglobals<rustcinterface[]::interface::runcompiler<core[]::result::Result<(), rustcspan[]::ErrorGuaranteed, rustcdriverimpl[]::runcompiler::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure}::{closure}, core[]::result::Result<(), rustcspan[]::ErrorGuaranteed::{closure} as core[]::ops::function::FnOnce<()::callonce::{shim:vtable} 28: 0x7f6adfe3d8e5 - <alloc::boxed::Box<F,
Code change:
} let feed_visibility = |this: &mut Self, def_id| { <del> let vis = this.r.tcx.visibility(def_id).expect_local(); </del> <ins> let vis = this.r.tcx.visibility(def_id); let vis = if vis.is_visible_locally() { vis.expect_local() } else { this.r.dcx().span_delayed_bug( span, "error should be emitted when an unexpected trait item is used", ); rustc_middle::ty::Visibility::Public }; </ins> this.r.feed_visibility(this.r.local_def_id(id), vis); };

Related discussion:
text: Aas core::ops::function::FnOnce<Args::callonce::h5d7c8f150ab9c84c at 29: 0x7f6adfe3d8e5 - <alloc::boxed::Box<F,Aas core::ops::function::FnOnce<Args::callonce::h570d5b005c242c15 at 30: 0x7f6adfe3d8e5 - std::sys::unix::thread::Thread::new::threadstart::h36b0a20c0b2361ad at 31: 0x7f6ad9e97ada - <unknown32: 0x7f6ad9f2847c - <unknown33: 0x0 - <unknownerror: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.76.0-beta.1 ( 2023-12-21) running on x8664-unknown-linux-gnu note: compiler flags: --crate-type bin -C embed-bitcode=no -C debuginfo=2 -C incremental=[REDACTED] note: some of the compiler flags provided by cargo are hidden query stack during panic: [resolverfor_lowering] getting the resolver for lowering end of query stack
That is line 18 to 33
WG-prioritization assigning priority (). label -I-prioritize +P-medium
An interesting issue, claim
interesting that the crash also doesn't happen if we qualify the trait with instead of the crate's name.
The is interpreted as referring to an external crate, whereas not
right; i'm assuming it hits a different resolver codepath, despite both working the same if the referred ident is public. thanks for the quick fix!
Code change:
<ins> // unit-test: Inline // compile-flags: --crate-type=lib -C panic=abort use std::any::Any; use std::any::TypeId; struct A<T: ?Sized + 'static> { a: i32, b: T, } // EMIT_MIR dont_inline_type_id.call.Inline.diff pub fn call<T: ?Sized + 'static>(s: &T) -> TypeId { s.type_id() } </ins>

Related discussion:
text: <!-- 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: The three printed TypeIds should be identical, as with the behavior in Rust <=1.70 Instead, this happened: switch between rust versions. I could not find reference in the that could explain such behavioral changes.
if my bisection is correct, this surfaced in commit cc (makes sense?)
I do not believe that is the correct PR to point at. Bisecting anything related to MIR opts can be tricky because you need to stabilize the MIR opt pipeline against changes like in that PR which don't actually implement any new behavior, they just change the meaning of MIR opt levels. Try bisecting with ? The above PR just changes the opt level 3 inliner behavior to be the default.
Reproduces since before with
This has to do with the fact that this impl: ... applies even when . Therefore in a polymorphic function like , we're eagerly inlining from that impl even though during monomorphization we'd prefer the built-in candidate instead. This seems problematic.
WG-prioritization assigning priority (). label -I-prioritize +P-high