Question: { 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

<!-- 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


Question: 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> {

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


Question: } 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); }

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


Question: <ins> #![u={static N;}] fn main() {} </ins>

<!-- 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.


Question: <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>

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.


Question: <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>

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.


Question: '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> }

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.


Question: 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>

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.


Question: 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>

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.


Question: <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>

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.


Question: <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>

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.


Question: } 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); };

<!-- 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},


Question: } 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); };

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,


Question: } 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); };

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!


Question: <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>

<!-- 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


Question: #[inline] unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { <ins> // See the comment above in `alloc` for why this check looks the way it does. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::calloc(layout.size(), 1) as *mut u8 } else {

The man page for says And yet Miri found libstd calling this function with an alignment of 4 on a 64bit-platform. This happens when size=2, align=4. The fact that size<align makes it enter the code path for .
The only reason I can imagine for to exist there is a buggy implementation of . This check is only meaningful if a buggy implementation returns not an allocation suitably aligned for any built-in type (on x86_4 – 16-bytes) but rather an allocation aligned for the particular request?
A lack of comment is disturbing here. If git history does not reveal any such issue, then we should just remove that check entirely.
That extra check was introduced by to fix
I have opened in jemalloc to get clarification from them about their alignment guarantees. It would be nice if someone with more knowledge could chime in, in particular knowledge about where exactly that value of 16 for on x86-64 comes from. Cc
Possibly from here:
C has types with an alignment smaller than are supported in all contexts. AFAICT this includes the memory returned by any memory allocation function - not only , but also . The largest scalar type of C implementations needs to be supported in all contexts. On most platforms, this type is often which the requires it to have an alignment of 16, so on these particular platforms, will have an alignment requirement of 16 bytes. On these platforms, all memory allocation functions need to return memory aligned to a 16 byte boundary when called with a to be able to support the largest scalar type provided by the C implementation. Otherwise would return memory not suitable for storing a scalar type. However, if the memory allocation is smaller than the size of the largest scalar type, then it would be illegal to store it there, so the memory returned needs to only be properly aligned to be able to store the largest scalar type that would fit in that particular size. In practice, this means that for sizes up to , the alignment of the returned memory equals the size of the allocation rounded to the previous power of two (e.g. in a 5 byte allocation, you can at most fit a 32-bit scalar, so the allocation only needs 4 byte of alignment). And for sizes larger than , the alignment is at least (this allows storing, e.g., an array of s).


Question: #[inline] unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { <ins> // See the comment above in `alloc` for why this check looks the way it does. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::calloc(layout.size(), 1) as *mut u8 } else {

In practice, the fastest thing you can do, is calling malloc if , because if malloc will return an alignment of at least rounded to the previous power of two, which is always satisfied (remember that must be a power of two, so if its smaller than size, it is at least the previous one). will do this without having to branch on any user provided alignment argument. That's precisely what that code is doing. The else branch is calling a "generic" which should be able to handle any user-specified alignment. The implementation of based on : appears to have the bug you mention, and should probably call or similar. I suspect that the implementation of provided by jemalloc, which we use here: doesn't have this issue, because it probably just forwards the call to , which supports alignment smaller than .
So basically on the C side, one assumes that is not used with types that use the C equivalent of ? With that assumption, I agree it is enough for to guarantee an alignment of rounded down to the next power of two. (I think your post originally said "up", but now it says "down" so I guess we agree.) That's what I and our implementation indeed handles that case just fine. The bug in the way we call is fixed by Still, it would be nice not to be able to reason about "in practice", but get some commitment from jemalloc -- see And finally, this only concerns on Unixes. Does anyone know what the situation looks like with on Windows? libstd currently assumes even small allocations to be aligned there, and agrees with that (Ctrl-F "on 64-bit platforms").
EDIT: C11 to C, but yes, malloc doesn't know anything about the alignment of a type. It still can be used, but the user needs to check whether the allocation is properly aligned. The docs are quite clear IMO: Anything more concrete than that will be target specific, and those details are outside jemalloc's control - if jemalloc wants to replace the system allocator in a target, it needs to comply with the ABI there. If it were to guarantee more, e.g., all allocations are 16byte aligned, it wouldn't work on platforms using the SysV i386 ABI.
Well, with that statement from the jemalloc docs is wrong, isn't it?


Question: #[inline] unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { <ins> // See the comment above in `alloc` for why this check looks the way it does. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::calloc(layout.size(), 1) as *mut u8 } else {

And for users to manually do the alignment, getting something more concrete would be useful. And also for Rust! Currently you are deducing a whole lot of things from a few words in the spec. I have zero confidence that this is the only way to read the spec. So something like: "for we guarantee an alignment of ; for smaller sizes we guarantee an alignment of the size rounded down to the next power of two." would IMO be prudent to ask from the jemalloc devs. Or else we'll find ourselves with more bugs when someone interprets all this slightly differently.
I don't know how useful would that be: malloc only needs to comply with the C standard. Parts of it are implementation-defined, and what those are defined to is often specified by the system ABI. That's the only thing the global allocator can rely on. On most platforms, the system allocator - which is the default global allocator for Rust programs - is not jemalloc - it is the one from glibc, musl, microsoft, apple, google, mozilla, etc. In some platforms, like FreeBSD, the system allocator is jemalloc, but even there we can't exploit that knowledge because users can just and now the global allocator is a different one. That's an use case we support. So even if jemalloc were to offer extra guarantees here, Rust's system allocator cannot make use of them. The only places were we can can exploit jemalloc's specific guarantees, is when using crates like jemallocator, to explicitly hardcode the allocator to a particular one. As in, if that allocator is not linked, you get a linker error or similar. But even there, it makes sense to stick to what C and the platform ABI guarantees, because jemalloc is free to break anything else in the next version.
Well it would save us this entire discussion. If that doesn't demonstrate its usefulness I don't know what does.^^ I don't know what the "system allocator" is for Linux, but the one in glibc actually guarantees a 16-byte alignment on 64bit systems for all allocations. So by that standard jemalloc would just be incorrect.
The platform ABI guarantees that. What the malloc implementations guarantee is irrelevant.


Question: #[inline] unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { <ins> // See the comment above in `alloc` for why this check looks the way it does. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::calloc(layout.size(), 1) as *mut u8 } else {

If glibc were to guarantee that all addresses are 32-byte aligned, there is no way in which we could exploit that information in the implementation of the system allocator, because the platform only requires 16-byte alignment, and it is valid to pick any allocator at run-time that satisfies that.
So there a document somewhere saying "for x86-64 bit, 16-byte alignment is guaranteed"? But that document contains an exception for small sizes, making s behavior legal?
Yes, there are documents containing the rules of what's legal, at least for Linux x8664. Those document allow an exception for small sizes. One API that uses those is , which requires the alignment to be at least , which is 8 on x86_64, and which allows you to allocate bytes, with a smaller alignment. I still have no idea what jemalloc has to do with any of this - your original question is about , and that has nothing to do with jemalloc. But yes, jemalloc exploits this behavior, to be able to satisfy 1 byte request, and return addresses that are 1 byte aligned. Otherwise each 1 byte request would consume 16 bytes of memory within a memory page.
A document that could be relevant is the C standard. Unfortunately, as mentioned in the commit message for , it is rather tautological on this topic: The standard does not give any numeric value. Like many other aspects of C, it looks like the actual value of is implementation-defined.
When using jemalloc, becomes jemalloc. That's how happened. Do you have a reference for something that concretely calls out an exception for small types? The C standard only does this very indirectly, as you showed.
That was a bug in our implementation of system that applies to pretty much all allocators, not only jemalloc. says (emphasis mine): Since the alignment of an object is a power of two that is always smaller than or equal to the object size, rounding down the alignment of an allocation to the previous power of two always produces an allocation properly aligned for every type that can fit it. That holds for all allocations, so there is no exception for that. That's the rule. Since that would mean that large allocations must be unreasonably aligned, the standard does provide an exception for allocations of size larger than than .


Question: #[inline] unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { <ins> // See the comment above in `alloc` for why this check looks the way it does. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::calloc(layout.size(), 1) as *mut u8 } else {

These only need to be aligned at an boundary. If you believe this is incorrect, please show a counter-example for which this doesn't work.
AFAIK it is a normal way of using to make it override the symbol? Don't we still do that in rustc, or when using "jemallocator"? I don't say it is incorrect, I say it is awfully indirect. It's like reading tea leaves. I am looking for a clear definite statement. That doesn't seem to exist though. :( There clearly is some kind of "non-continuity" where all allocations are aligned MINALIGN except for small ones. Or vice versa, all allocations are aligned "size rounded down to power of 2" except for big ones. You are convincingly deriving that non-continuity from standard wording. I don't say you are wrong, but this feels like interpreting ancient scripture. A clear spec looks different. Also, an object of size 2 with alignment requirement 4 is "fundamental" according to your definition, and yet rounding down the size to the next power of 2 does not give the right alignment. So your rule does have exceptions, namely types marked .
Can you show such an object in C and/or Rust ? It's probably the most common way of switching allocators. What does is it requires to be linked to your binary, allowing (and making use of) jemalloc-specific APIs. If you do this, when using directly (not ), you can obviously rely on assumptions that only hold for . But cannot do that because, then it wouldn't work with other allocators.
The goal is not to rely on assumptions that only hold for . The goal is to make sure that we do not make assumptions that don't hold for . Because that's what we used to do, before got fixed. We were assuming something that was true for system but not for : that all allocations, no matter the size, are aligned. To make sure we don't do that again, I want to be sure that all assumptions we are making hold for . That's why I'd like jemalloc to spell out what we can assume.
Ah I forgot about the stride vs. size thing. So such an object does not exist.


Question: #[inline] unsafe fn alloc_zeroed(&self, layout: Layout) -> *mut u8 { <ins> // See the comment above in `alloc` for why this check looks the way it does. </ins> if layout.align() <= MIN_ALIGN && layout.align() <= layout.size() { libc::calloc(layout.size(), 1) as *mut u8 } else {

But such a exists, and it is something we want to support in our allocator API (we even have a test for that). And we do have objects with align size, namely all ZST.
Yeah, I agree. The only cases for which the "round to the previous power of two approach" doesn't work is for ZSTs, and types (or allocations) with align size. Since those just cannot happen in C, the C standard doesn't mention them as exceptions. That is, we can only call when that holds, and if it that doesn't hold, we need to call a different API that supports the align size case.


Question: <ins> //@ edition:2021 macro_rules! a { ( ) => { impl<'b> c for d { e::<f'g> //~ ERROR prefix `f` is unknown } }; } fn main() {} </ins>

<!-- ICE: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced


Question: Ok(pat) } <ins> /// Recover from a typoed `...` pattern that was encountered /// Ref: Issue #70388 fn recover_dotdotdot_rest_pat(&mut self, lo: Span) -> PatKind { // A typoed rest pattern `...`. self.bump(); // `...` // The user probably mistook `...` for a rest pattern `..`. self.struct_span_err(lo, "unexpected `...`") .span_label(lo, "not a valid pattern") .span_suggestion_short( lo, "for a rest pattern, use `..` instead of `...`", "..".to_owned(), Applicability::MachineApplicable, ) .emit(); PatKind::Rest } </ins> /// Try to recover the more general form `intersect ::= $pat_lhs @ $pat_rhs`. /// /// Allowed binding patterns generated by `binding ::= ref? mut? $ident @ $pat_rhs`

` The problem here is that we have instead of The compiler however points towards in the error message instead of the superfluous : Fun fact: when using four dots , it correctly points at the last dot :) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
seems like a simple issue to fix. If I were to take a shot at fixing this, where would I start?
Mentoring instructions: Add a branch after this one... instead of , check that . This should be interpreted as a as in the previous branch, but an error should also be emitted. (Add the code for error emission in a separate method, with an appropriate , where the span of the is replaced with . See for an example on emitting an error with a suggestion.)
Sure thing! Will get to it right after work. Thanks for the pointers.
assign


Question: // Change value between simple literals --------------------------------------- <del> #[cfg(cfail1)] const CONST_CHANGE_VALUE_1: i16 = 1; #[cfg(not(cfail1))] </del> #[rustc_clean(cfg="cfail2", except="HirBody")] #[rustc_clean(cfg="cfail3")] #[rustc_metadata_clean(cfg="cfail3")] <del> const CONST_CHANGE_VALUE_1: i16 = 2; </del> <ins> const CONST_CHANGE_VALUE_1: i16 = { #[cfg(cfail1)] { 1 } #[cfg(not(cfail1))] { 2 } }; </ins> <del> // Change value between expressions ------------------------------------------- #[cfg(cfail1)] const CONST_CHANGE_VALUE_2: i16 = 1 + 1; #[cfg(not(cfail1))] </del> <ins> // Change value between expressions ------------------------------------------- </ins> #[rustc_clean(cfg="cfail2", except="HirBody")] #[rustc_clean(cfg="cfail3")] #[rustc_metadata_dirty(cfg="cfail2")] #[rustc_metadata_clean(cfg="cfail3")] <del> const CONST_CHANGE_VALUE_2: i16 = 1 + 2; </del> <ins> const CONST_CHANGE_VALUE_2: i16 = { #[cfg(cfail1)] { 1 + 1 } </ins> <del> #[cfg(cfail1)] const CONST_CHANGE_VALUE_3: i16 = 2 + 3; </del> <ins> #[cfg(not(cfail1))] { 1 + 2 } }; </ins> <del> #[cfg(not(cfail1))] </del> #[rustc_clean(cfg="cfail2", except="HirBody")] #[rustc_clean(cfg="cfail3")] #[rustc_metadata_dirty(cfg="cfail2")] #[rustc_metadata_clean(cfg="cfail3")] <del> const CONST_CHANGE_VALUE_3: i16 = 2 * 3; </del> <ins> const CONST_CHANGE_VALUE_3: i16 = { #[cfg(cfail1)] { 2 + 3 } </ins> <del> #[cfg(cfail1)] const CONST_CHANGE_VALUE_4: i16 = 1 + 2 * 3; </del> <ins> #[cfg(not(cfail1))] { 2 * 3 } }; </ins> <del> #[cfg(not(cfail1))] </del> #[rustc_clean(cfg="cfail2", except="HirBody")] #[rustc_clean(cfg="cfail3")] #[rustc_metadata_dirty(cfg="cfail2")] #[rustc_metadata_clean(cfg="cfail3")] <del> const CONST_CHANGE_VALUE_4: i16 = 1 + 2 * 4; </del> <ins> const CONST_CHANGE_VALUE_4: i16 = { #[cfg(cfail1)] { 1 + 2 * 3 } #[cfg(not(cfail1))] { 1 + 2 * 4 } }; </ins> // Change type indirectly -----------------------------------------------------

Found via rust-icci: https://travis- The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode: I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows: There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages. This is another span-related papercut cc
Full IR files for reference:


Question: <ins> // Copyright 2017 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. // ignore-tidy-linelength // compile-flags: -g  --remap-path-prefix={{cwd}}=/the/aux-cwd --remap-path-prefix={{src-base}}/remap_path_prefix/auxiliary=/the/aux-src #![crate_type = "lib"] pub fn foo<T>() {} </ins>

STR (on Linux): file that has generics usage () code DWARF info Notice that contains such entries as , possibly produced by the fact that "" is a relative path and DWATcompdir is set to "/home/yury". It is expected for core files to have absolute path e.g. ""
cc I wonder what interaction (path rewriting?) causes this result.
FWIW, produces that shows that !DIFile entries has the directory field empty (and the filename is relative)
It is a regression, since +stable has absolute locations, e.g.
could this have to do with
Likely so! I'll try to look into this in the near future
Ok so the change here can be exhibited with this script: If you execute that script you see: but if you remove you see: It appears that if upstream crates (like libstd) use then their filename is listed as the original relative source file instead of the absolute path name that it had previous to when it wasn't compiled with . So somehow using to compile libstd is affecting downstream crates to have relative path names instead of old absolute path names. It makes sense to me that the absolute path name goes away with (that is the whole point after all) but ideally it'd still be an absolute path, just applying the mapping. would you be able to help point me in the direction of where this change in logic might happen? If so I can test out a patch!
This should be what you're looking for: One solution would be to compile libstd with absolute paths and apply proper remapping to those.
Ah that's perfect! I'll see if I can work up a solution to that soon


Question: <ins> error[E0531]: cannot find tuple struct or tuple variant `Cons` in this scope --> $DIR/issue-90113.rs:17:9 | LL |         Cons(..) => {} |         ^^^^ not found in this scope | help: consider importing this tuple variant | LL | use list::List::Cons; | error: aborting due to previous error For more information about this error, try `rustc --explain E0531`. </ins>

Bisected to a rollup, but I think it's very likely to be . cc searched nightlies: from nightly-2021-10-01 to nightly-2021-10-19 regressed nightly: nightly-2021-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
The old suggestion was actually incorrect because it suggested , which is a private import. However, the new error is "more incorrect" IMO since it says something confusing (and incorrect).
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium


Question: /// assert_eq!(*x, 1); /// ``` #[inline] <del> #[unstable(feature = "mutex_unpoison", issue = "96469")] </del> <ins> #[stable(feature = "mutex_unpoison", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn clear_poison(&self) { self.poison.clear(); }

Feature gate: This is a tracking issue for functions to clear the poisoned flag on and . [x] [x] Implementation: [x] Final comment period (FCP) [ ] Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final comment period (FCP) is always needed before stabilization. This works as follows: A library API team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final comment period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
Hi, I read (wich got automatically closed by the way) and the PR It seems all good. What is the next step to make it in the stable API ? Can I help somehow ?
Hi, sorry if flooding but are there any updates regarding this issue?
I think the next step is one of the rust developers needs to start the final comment period. IDK what the criteria for doing so are.
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [ ] [x] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
I was wondering whether the idea of had been considered and found that addressed it. SGTM!


Question: /// assert_eq!(*x, 1); /// ``` #[inline] <del> #[unstable(feature = "mutex_unpoison", issue = "96469")] </del> <ins> #[stable(feature = "mutex_unpoison", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn clear_poison(&self) { self.poison.clear(); }

:bell: This is now entering its final comment period, as per the . :bell:
Given the state change this method causes, I am curious about rationale behind using vs ?
If it took , it wouldn't be possible to unpoison a mutex shared between threads despite that being the main case where poisoning can happen.
I just want to add that probably before stabilizing this method we should implement a lint which catches invalid patterns of using these methods since it is very easy to misuse. Or, at the very least, include information about potential footgun in documentation for these methods.
What kind of lint do you exactly want? What are the patterns in question that you are worried about?
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
exactly the possible error outlined by Mara Bos: calling before acquiring a lock. The only way this usage is correct is when no other thread can act on mutex - either because they don't exist or because they are all blocked on something else. I believe that these situations are rare enough to flag such a pattern as at least suspicious.
If unpoison was a method of PoisonError or of MutexGuard instead of mutex, would it prevent such problems?
That was discussed here:


Question: fn main() { macro_rules! test { <del> ($($fn_name:ident,)*) => { $( </del> <ins> ($($fn_name:expr,)*) => { $( </ins> test_future_yields_once_then_returns($fn_name); )* } } <ins> macro_rules! test_with_borrow { ($($fn_name:expr,)*) => { $( test_future_yields_once_then_returns(|x| { async move { await!($fn_name(&x)) } }); )* } } </ins> test! { async_block, async_nonmove_block, async_closure, async_fn, async_fn_with_internal_borrow, <ins> |x| { async move { unsafe { await!(unsafe_async_fn(x)) } } }, } test_with_borrow! { async_block_with_borrow_named_lifetime, async_fn_with_borrow, async_fn_with_borrow_named_lifetime, async_fn_with_impl_future_named_lifetime, |x| { async move { await!(async_fn_with_named_lifetime_multiple_args(x, x)) } }, </ins> } }

suggested this is because when we lower the async function, we add `), whereas it should be parented as something outside of the impl trait context (as that is how such an expression would be parented, if it actually existing in the AST). I have a bit of code where I'd like to use a reference with a lifetime in an "async" function, which panics the compiler. I tried this code: I expected to see this happen: My understanding was that async functions are allowed to take references as parameters. helped to debug this a little bit and there is a suspicion that named lifetimes are somehow not properly propagated. I stumbled into this because I wanted to have 2 args with references, but if the lifetimes are elided the compiler asks for them to be . Adding them ICEs the compiler. Instead, this happened: I got a compiler panic. Backtrace:
suggested might be related
It would appear one can workaround this by using async blocks manually: I still need to test this does what I expect.
why do you need the immediately invoked closure there,
Yeah, just noticed. I think I also had some other issue / ICE, but I don't remember exactly what it was. Gonna have to check it again. Also, I don't think I knew that on blocks was a thing.
I didn't quite understand why I needed the move. I am trying to fix the original ICE, I think I got some time today tomorrow, hopefully, will make some progress. But compiler newbie, so might not work out.
You need to move to avoid the closure borrowing the references locally. It's the same situation as with I just removed all immeditaly invoked functions from eval :wink:
I am playing around with similar types of borrowing patterns, namely using StreamObj to carry a stream around inside of a struct. I can't seem to use the posted work-arounds: I am taking this working code and I'm refactoring it. Starts as: this works, compiles and runs. Then I try my hand at refactoring to move the stream out of the same scope as the await code pulling out values.


Question: fn main() { macro_rules! test { <del> ($($fn_name:ident,)*) => { $( </del> <ins> ($($fn_name:expr,)*) => { $( </ins> test_future_yields_once_then_returns($fn_name); )* } } <ins> macro_rules! test_with_borrow { ($($fn_name:expr,)*) => { $( test_future_yields_once_then_returns(|x| { async move { await!($fn_name(&x)) } }); )* } } </ins> test! { async_block, async_nonmove_block, async_closure, async_fn, async_fn_with_internal_borrow, <ins> |x| { async move { unsafe { await!(unsafe_async_fn(x)) } } }, } test_with_borrow! { async_block_with_borrow_named_lifetime, async_fn_with_borrow, async_fn_with_borrow_named_lifetime, async_fn_with_impl_future_named_lifetime, |x| { async move { await!(async_fn_with_named_lifetime_multiple_args(x, x)) } }, </ins> } }

Now I can get the same ICE as this ticket: ICE: full backtrace: Then I try some of your posted workarounds and they don't do the trick, here's my best try: but this fails to compile due to an ownership issue I can't figure out:
your final borrow error is because Fahrenheit while your contains a local stack borrow. You could try using  instead of Fahrenheit.
Alternatively to what suggested, you could move the code in to an async fn:


Question: <ins> error[E0597]: `a` does not live long enough --> $DIR/location-insensitive-scopes-issue-117146.rs:10:18 | LL |     let b = |_| &a; |             --- -^ |             |   || |             |   |borrowed value does not live long enough |             |   returning this value requires that `a` is borrowed for `'static` |             value captured here ... LL | } | - `a` dropped here while still borrowed | note: due to current limitations in the borrow checker, this implies a `'static` lifetime --> $DIR/location-insensitive-scopes-issue-117146.rs:20:22 | LL | fn bad<F: Fn(&()) -> &()>(_: F) {} |                      ^^^ error: implementation of `Fn` is not general enough --> $DIR/location-insensitive-scopes-issue-117146.rs:13:5 | LL |     bad(&b); |     ^^^^^^^ implementation of `Fn` is not general enough | = note: closure with signature `fn(&'2 ()) -> &()` must implement `Fn<(&'1 (),)>`, for any lifetime `'1`... = note: ...but it actually implements `Fn<(&'2 (),)>`, for some specific lifetime `'2` error: implementation of `FnOnce` is not general enough --> $DIR/location-insensitive-scopes-issue-117146.rs:13:5 | LL |     bad(&b); |     ^^^^^^^ implementation of `FnOnce` is not general enough | = note: closure with signature `fn(&'2 ()) -> &()` must implement `FnOnce<(&'1 (),)>`, for any lifetime `'1`... = note: ...but it actually implements `FnOnce<(&'2 (),)>`, for some specific lifetime `'2` error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0597`. </ins>

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
cc removing the println macro from around the match avoids the ice :thinking:
Fun :)
A more minimal version would be:


Question: # 32/64-bit MinGW builds. # <del> # The MinGW builds unfortunately have to both download a custom toolchain and # avoid the one installed by AppVeyor by default. Interestingly, though, for # different reasons! </del> <ins> # We are using MinGW with posix threads since LLVM does not compile with # the win32 threads version due to missing support for C++'s std::thread. </ins> # <del> # For 32-bit the installed gcc toolchain on AppVeyor uses the pthread # threading model. This is unfortunately not what we want, and if we compile # with it then there's lots of link errors in the standard library (undefined # references to pthread symbols). # # For 64-bit the installed gcc toolchain is currently 5.3.0 which # unfortunately segfaults on Windows with --enable-llvm-assertions (segfaults # in LLVM). See rust-lang/rust#28445 for more information, but to work around # this we go back in time to 4.9.2 specifically. </del> <ins> # Instead of relying on the MinGW version installed on appveryor we download # and install one ourselves so we won't be surprised by changes to appveyor's # build image. </ins> # # Finally, note that the downloads below are all in the `rust-lang-ci` S3 # bucket, but they cleraly didn't originate there! The downloads originally # came from the mingw-w64 SourceForge download site. Unfortunately # SourceForge is notoriously flaky, so we mirror it on our own infrastructure. <del> # # And as a final point of note, the 32-bit MinGW build using the makefiles do # *not* use debug assertions and llvm assertions. This is because they take # too long on appveyor and this is tested by rustbuild below. </del> - MSYS_BITS: 32 RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja SCRIPT: python x.py test MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 - MSYS_BITS: 64 SCRIPT: python x.py test RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 # 32/64 bit MSVC and GNU deployment

The AVR-Rust post continues to track AVR-LLVM, which is tracking upstream LLVM. That means we are running into changes from the future LLVM 4.0. I figured we could open up this issue now to track the changes required to stay compatible. This is the current list of upgrade hazards. Note that some of the text may be nonsensical as I don't truly grok all the internals of LLVM so some changes are wild stabs in the dark. It's also possible that some failed fix for earlier problems actually caused later problems: [x] DIDescriptorFlags became a real C++ enum and not a bitset () [x] An EH personality is required for every function that can unwind () [x] pass changed header and constructor name () [x] changed API () [x] Bitcode/ReaderWriter.h has been renamed / API changed () () [x] changed API () [x] changed API () [x] prefers over () [x] string type changes () [x] is not guaranteed to be null terminated () [x] changed return types () [x] Archive support changed error handling types () [x] Teach Rust about an LLVM 4.0 API change for creating debug info for global variables () [x] Check all errors in LLVMRustArchiveIterator API () [x] Upgrade emscripten (kripken/emscripten-fastcomp, kripken/emscripten-fastcomp-clang) [x] Alignment now represented with 32 bits instead of 64 () [x] API changed again () [x] now takes an instead of a and () [x] Symbol lookup error when linking dylibs () [x] Undefined behavior in tests () [x] Unoptimised builds of compilerbuiltins on ARM have references to () A WIP PR that performs the upgrade! Some issues whose resolution is believed to be blocked on LLVM 4.0: [ ]
Next time we do this upgrade we'll need emscripten to do it to. It would be good if we could pull in a working llvm wasm backend in the same upgrade, but that may not be ready before the end of the year.
For the record, I am also working with a fork of LLVM that is tracking upstream (not AVR-LLVM but similar in spirit) and am starting to work on this now.


Question: # 32/64-bit MinGW builds. # <del> # The MinGW builds unfortunately have to both download a custom toolchain and # avoid the one installed by AppVeyor by default. Interestingly, though, for # different reasons! </del> <ins> # We are using MinGW with posix threads since LLVM does not compile with # the win32 threads version due to missing support for C++'s std::thread. </ins> # <del> # For 32-bit the installed gcc toolchain on AppVeyor uses the pthread # threading model. This is unfortunately not what we want, and if we compile # with it then there's lots of link errors in the standard library (undefined # references to pthread symbols). # # For 64-bit the installed gcc toolchain is currently 5.3.0 which # unfortunately segfaults on Windows with --enable-llvm-assertions (segfaults # in LLVM). See rust-lang/rust#28445 for more information, but to work around # this we go back in time to 4.9.2 specifically. </del> <ins> # Instead of relying on the MinGW version installed on appveryor we download # and install one ourselves so we won't be surprised by changes to appveyor's # build image. </ins> # # Finally, note that the downloads below are all in the `rust-lang-ci` S3 # bucket, but they cleraly didn't originate there! The downloads originally # came from the mingw-w64 SourceForge download site. Unfortunately # SourceForge is notoriously flaky, so we mirror it on our own infrastructure. <del> # # And as a final point of note, the 32-bit MinGW build using the makefiles do # *not* use debug assertions and llvm assertions. This is because they take # too long on appveyor and this is tested by rustbuild below. </del> - MSYS_BITS: 32 RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja SCRIPT: python x.py test MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 - MSYS_BITS: 64 SCRIPT: python x.py test RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 # 32/64 bit MSVC and GNU deployment

I'm looking through the AVR-Rust commits and I'd love to coordinate --- feel free to ping me on IRC () or via mail!
Note that there is a regression reported against llvm 4.0 regarding the powi intrinsic on armhf targets: I'm explicitly mentioning this here, because there were previously problems with it, see and related issues. Also cc rust-lang-nursery/compiler-builtins, an issue about the same problem in the compiler-rt rust port.
To clarify what I think the is referring to (correct me if I'm wrong) In LLVM 3.9 and before, the calling convention LLVM used with the powidf2 and powisf2 intrinsics was basically the C calling convention In LLVM 4.0, the backend was corrected to expect these intrinsics to have the aapcs calling convention One person that aapcs is expected for powis2f and powid2f, while another a claiming that the normal C calling convention should be used. So it seems that if the LLVM change is not reverted (expected powisf2 to be aapcs) then we need to update our definition. This is going to be a huge PITA for supporting multiple LLVM versions as well. We need to select the calling convention depending on the LLVM version as well...
Any objections to doing that coordination here on GitHub, or on one of our forks?
I don't have strong preferences for the communication channel.
should address what is listed as API changes" above (the core of the change is in how attributes are represented).
I would prefer to upstream LLVM 4.0 compatibility patches sooner rather than later. That includes my own work obviously, but I'm also looking at the commits I cherry-picked from AVR-Rust. In particular, looks like a reasonable simplification even independent of LLVM 4.0 compatibility, and looks like a nice little self-contained fix. Could you create PRs for those? (If you don't have the time but are otherwise fine with upstreaming, I'd be happy to manage that, giving proper credit of course.)
Absolutely! I wasn't really sure how much we could expect LLVM 4 to change as it goes towards stable / how much churn the Rust maintainers would want to put up with. I'll get those pulled out and submitted soon. I think I'm also starting to understand some of the silly error handling that the new LLVM does.


Question: # 32/64-bit MinGW builds. # <del> # The MinGW builds unfortunately have to both download a custom toolchain and # avoid the one installed by AppVeyor by default. Interestingly, though, for # different reasons! </del> <ins> # We are using MinGW with posix threads since LLVM does not compile with # the win32 threads version due to missing support for C++'s std::thread. </ins> # <del> # For 32-bit the installed gcc toolchain on AppVeyor uses the pthread # threading model. This is unfortunately not what we want, and if we compile # with it then there's lots of link errors in the standard library (undefined # references to pthread symbols). # # For 64-bit the installed gcc toolchain is currently 5.3.0 which # unfortunately segfaults on Windows with --enable-llvm-assertions (segfaults # in LLVM). See rust-lang/rust#28445 for more information, but to work around # this we go back in time to 4.9.2 specifically. </del> <ins> # Instead of relying on the MinGW version installed on appveryor we download # and install one ourselves so we won't be surprised by changes to appveyor's # build image. </ins> # # Finally, note that the downloads below are all in the `rust-lang-ci` S3 # bucket, but they cleraly didn't originate there! The downloads originally # came from the mingw-w64 SourceForge download site. Unfortunately # SourceForge is notoriously flaky, so we mirror it on our own infrastructure. <del> # # And as a final point of note, the 32-bit MinGW build using the makefiles do # *not* use debug assertions and llvm assertions. This is because they take # too long on appveyor and this is tested by rustbuild below. </del> - MSYS_BITS: 32 RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja SCRIPT: python x.py test MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 - MSYS_BITS: 64 SCRIPT: python x.py test RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 # 32/64 bit MSVC and GNU deployment

Awesome, thanks in advance!
BTW the PR reference for "llvm::AttrBuilder changed API" is wrong, it points at this issue instead of
Does anyone have ETA? I'd like to know when I can use AVR. :)
You should follow along at avr-rust/rust for the AVR-specific issues. Upgrading to LLVM 4 will not magically yield AVR support.
Ok, thank you!
I've created for the API change.
I've also created for another debug info API change.
After putting all of those patches on top of master, was successfully built. I got several undefined references, most likely due to my local LLVM setup.
I think the next step after all those patches land is to allow LLVM 4.0 in the configure/rustbuild scripts and then actually update the submodule.
We'll also need to fix that AAPCS bug first, I just noticed it
Don't forget : I think that means that the Rust fork of LLVM is following the Emscripten fork of LLVM, thus Emscripten needs to upgrade to LLVM 4.0 / master before Rust can.
And I'm hoping to supersede it with
I just ran into which changed the alignment from u64 to u32. Will think about a proper fix later, unless someone beats me to it (but should merge first to avoid further conflicts).
And it says So, that will be "exciting".
Is there much left blocking an upgrade?
This: Has to be done too but I don't know if it's currently being worked on. Any info on that ^?
No nobody is actively working on an emscripten upgrade. Since even when that is done it will probably take a lot of work to land an LLVM upgrade, there's probably more we can do to prepare. Once we decide we want to do it, somebody can prepare a patch to throw at the bots. It seems likely stuff will not work and it will be a slog to fix it all, which will give us time. We don't need emcc to generate wasm stds, just a fairly small patch on our LLVM branch that will hopefully port without much difficulty. So if somebody feels motivated, it's not too soon to start going after it. As to the emscripten upgrade, we should at least let know that we're starting to think seriously about doing the upgrade, and need emscripten to upgrade LLVM too.


Question: # 32/64-bit MinGW builds. # <del> # The MinGW builds unfortunately have to both download a custom toolchain and # avoid the one installed by AppVeyor by default. Interestingly, though, for # different reasons! </del> <ins> # We are using MinGW with posix threads since LLVM does not compile with # the win32 threads version due to missing support for C++'s std::thread. </ins> # <del> # For 32-bit the installed gcc toolchain on AppVeyor uses the pthread # threading model. This is unfortunately not what we want, and if we compile # with it then there's lots of link errors in the standard library (undefined # references to pthread symbols). # # For 64-bit the installed gcc toolchain is currently 5.3.0 which # unfortunately segfaults on Windows with --enable-llvm-assertions (segfaults # in LLVM). See rust-lang/rust#28445 for more information, but to work around # this we go back in time to 4.9.2 specifically. </del> <ins> # Instead of relying on the MinGW version installed on appveryor we download # and install one ourselves so we won't be surprised by changes to appveyor's # build image. </ins> # # Finally, note that the downloads below are all in the `rust-lang-ci` S3 # bucket, but they cleraly didn't originate there! The downloads originally # came from the mingw-w64 SourceForge download site. Unfortunately # SourceForge is notoriously flaky, so we mirror it on our own infrastructure. <del> # # And as a final point of note, the 32-bit MinGW build using the makefiles do # *not* use debug assertions and llvm assertions. This is because they take # too long on appveyor and this is tested by rustbuild below. </del> - MSYS_BITS: 32 RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja SCRIPT: python x.py test MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 - MSYS_BITS: 64 SCRIPT: python x.py test RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 # 32/64 bit MSVC and GNU deployment

It seems like that could be a big effort. Another alternative is to use the LLVM wasm backend, but I still have not heard that it is generally usable yet. cc
I can look into the effort needed to update emscripten's fastcomp LLVM version, but I need to know a commit to aim for. Sounds like the goal here is 4.0, which hasn't released yet, so I guess I have to wait on that?
So far as AVR is concerned, any commit within the last month will do. There will likely be a few more months until 4.0 is actually tagged (every ~6 months a new release is made). It is quite common for projects to track LLVM master, which I'm personally a fan of.
But is it common to release snapshots from LLVM master? When LLVM itself only releases every 6 months, it seems incongruous for Rust to pick arbitrary snapshots in its 6-week release cycle.
LLVM 4.0 will branch in a week and the final release will happen in late feburary (schedule says 21st for final tag, but this is flexible IIRC).
From the llvm-dev mailing list:
branch has happened
An update on the "powidf2 / powisf2 calling convention changed" situation: The regression has been fixed on llvm master () however from what I can tell the fixes are not yet in the 4.0 branch, although the fix may be backported ().
I've started working on updating emscripten kripken/emscripten-fastcomp kripken/emscripten-fastcomp-clang I've also created a new bug requesting that the regression fix be merged into 4.0 .
says the emcc LLVM upgrade is ready to go. or are we prepared to begin the Rust LLVM upgrade? I think what needs to happen is to submit the Rust PR and start throwing it against the bots. Once it looks like that is close to landing then we'll have to coordinate both project's upgrades to minimize the breakage window where rustc and emcc have different backends. I'm not sure how best to do that - we might just try to upgrade as simultaneously as possible and accept up to a few days of breakage, or we might ask emscripten to stage their build such that they can swap their incoming branch right after we land to master.


Question: # 32/64-bit MinGW builds. # <del> # The MinGW builds unfortunately have to both download a custom toolchain and # avoid the one installed by AppVeyor by default. Interestingly, though, for # different reasons! </del> <ins> # We are using MinGW with posix threads since LLVM does not compile with # the win32 threads version due to missing support for C++'s std::thread. </ins> # <del> # For 32-bit the installed gcc toolchain on AppVeyor uses the pthread # threading model. This is unfortunately not what we want, and if we compile # with it then there's lots of link errors in the standard library (undefined # references to pthread symbols). # # For 64-bit the installed gcc toolchain is currently 5.3.0 which # unfortunately segfaults on Windows with --enable-llvm-assertions (segfaults # in LLVM). See rust-lang/rust#28445 for more information, but to work around # this we go back in time to 4.9.2 specifically. </del> <ins> # Instead of relying on the MinGW version installed on appveryor we download # and install one ourselves so we won't be surprised by changes to appveyor's # build image. </ins> # # Finally, note that the downloads below are all in the `rust-lang-ci` S3 # bucket, but they cleraly didn't originate there! The downloads originally # came from the mingw-w64 SourceForge download site. Unfortunately # SourceForge is notoriously flaky, so we mirror it on our own infrastructure. <del> # # And as a final point of note, the 32-bit MinGW build using the makefiles do # *not* use debug assertions and llvm assertions. This is because they take # too long on appveyor and this is tested by rustbuild below. </del> - MSYS_BITS: 32 RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja SCRIPT: python x.py test MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 - MSYS_BITS: 64 SCRIPT: python x.py test RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 # 32/64 bit MSVC and GNU deployment

needs to know the exact LLVM commit we're moving to as well, and that will become clear once the PR starts working through the queue. The stars are aligning. Let's make this happen. Thanks for doing the fastcomp upgrade.
We are not fully compatible with LLVM 4.0. I have heard from at least one person (on IRC) that building against stock LLVM 4.0 (RC) does not work. I haven't personally inspected all failures, but there's at least two things still missing: (and possibly ). It shouldn't be a conceptually difficult patch to apply the equivalent changes to rustc, but possibly a big diff. I haven't digested the implications yet, but it might be a relatively simple change localized to the function in that currently calls .
The fix has been merged into the 4.0 release (). I'm going to try and build Rust against stock LLVM 4.0 and figure out what needs modifying.
On top of what mentioned: now takes an instead of a and ()
I've got a half-baked patch to use the new signature for I'm not familiar enough with Rust internals to finish it off. I ran into a problem in as it is given a but in order to use we need a . We need to call in order to build an instance of .
I've opened for the change that mentioned. I've also opened for the 32-bit alignment change. I believe that is the only thing we need to update aside from these two PRs in order to get the compiler to successfully be built with LLVM 4.0.
So to summarize where we are with LLVM 4 (correct me if I'm wrong): 4.0 will be released in about 1 week (2/21). are no known issues with supporting LLVM 4.0, but there are probably issues that will be discovered once we try to use it in nightlies. runs on in-tree LLVM + LLVM 3.7 (so PRs haven't actually been tested on LLVM 4.0 yet). support LLVM back to ~3.6(?


Question: # 32/64-bit MinGW builds. # <del> # The MinGW builds unfortunately have to both download a custom toolchain and # avoid the one installed by AppVeyor by default. Interestingly, though, for # different reasons! </del> <ins> # We are using MinGW with posix threads since LLVM does not compile with # the win32 threads version due to missing support for C++'s std::thread. </ins> # <del> # For 32-bit the installed gcc toolchain on AppVeyor uses the pthread # threading model. This is unfortunately not what we want, and if we compile # with it then there's lots of link errors in the standard library (undefined # references to pthread symbols). # # For 64-bit the installed gcc toolchain is currently 5.3.0 which # unfortunately segfaults on Windows with --enable-llvm-assertions (segfaults # in LLVM). See rust-lang/rust#28445 for more information, but to work around # this we go back in time to 4.9.2 specifically. </del> <ins> # Instead of relying on the MinGW version installed on appveryor we download # and install one ourselves so we won't be surprised by changes to appveyor's # build image. </ins> # # Finally, note that the downloads below are all in the `rust-lang-ci` S3 # bucket, but they cleraly didn't originate there! The downloads originally # came from the mingw-w64 SourceForge download site. Unfortunately # SourceForge is notoriously flaky, so we mirror it on our own infrastructure. <del> # # And as a final point of note, the 32-bit MinGW build using the makefiles do # *not* use debug assertions and llvm assertions. This is because they take # too long on appveyor and this is tested by rustbuild below. </del> - MSYS_BITS: 32 RUST_CONFIGURE_ARGS: --build=i686-pc-windows-gnu --enable-ninja SCRIPT: python x.py test MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: i686-6.2.0-release-win32-dwarf-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: i686-6.2.0-release-posix-dwarf-rt_v5-rev1.7z </ins> MINGW_DIR: mingw32 - MSYS_BITS: 64 SCRIPT: python x.py test RUST_CONFIGURE_ARGS: --build=x86_64-pc-windows-gnu --enable-ninja MINGW_URL: https://s3.amazonaws.com/rust-lang-ci/rust-ci-mirror <del> MINGW_ARCHIVE: x86_64-6.2.0-release-win32-seh-rt_v5-rev1.7z </del> <ins> MINGW_ARCHIVE: x86_64-6.2.0-release-posix-seh-rt_v5-rev1.7z </ins> MINGW_DIR: mingw64 # 32/64 bit MSVC and GNU deployment

)~ 3.7 and will continue to support it until either: a. It's so old that it can be removed without bothering package maintainers b. We need at least version X in order to fix an important bug c. The API is so different from version Y that it's a huge pain to support will open a PR to update the submodule shortly after release but it will take a month to land due to: a. Waiting for emscripten ( -) b. Bugs in upstream c. Missed LLVM API changes d. Making bors happy e. All of the above
Thanks for the summary The only correction I'd make is that in your point (4) you can s/3.6/3.7/, but otherwise it's accurate :) If you'd like to start preparing a PR to update to LLVM 4.0 I don't think we need to block waiting for LLVM itself to release 4.0. Currently only one Travis builder runs on each PR but we could temporarily allow more builders running on an LLVM 4.0 PR to start weeding out bugs before it hits
I gave it a go but I don't think my git-fu (or patience) is strong enough to handle a big merge like this. What I can do is try to run rustc with upstream LLVM and file/fix issues as I find them. There is at least one issue remaining as of (details to come).
Whoever ends up doing the LLVM upgrade, please also upgrade the compiler-rt submodule so that the sanitizer related LLVM passes don't diverge from what the sanitizer runtimes expect.
In fact, if you upgrade before the release, they usually mention your project in the release notes. :)
So whats the next issue(s) to subscribe to in the race-to-AVR? :)
As says on , we can integrate the latest Rust master into the avr-rust compiler. After that, we can spend some time getting compiling for AVR. Once that is working, we could then start looking into upstreaming the AVR target to Rust.
AVR-specific issues can be raised / tracked in For example, there are two that I'm aware of right now:
has been closed, so that can be checked off in the top post.


Question: PYTHONPATH="$PYTHONPATH:$GDB_PYTHON_MODULE_DIRECTORY" exec ${RUST_GDB}  --directory="$GDB_PYTHON_MODULE_DIRECTORY"  -iex "add-auto-load-safe-path $GDB_PYTHON_MODULE_DIRECTORY"  <ins> -iex "set substitute-path /rustc/$RUSTC_COMMIT_HASH $RUSTC_SYSROOT/lib/rustlib/src/rust"  </ins> "$@"  No newline at end of file

I'm trying to use on project generated by and looks like the source code path is not configured:
Visited during wg-debugging's triage meeting. We think this is most likely still an issue but probably not a high priority one. If someone wants to work on this, the first thing they should do is retest and verify this is still broken (but we think it most likely is). There may be a fairly simple resolution to modify rust-gdb to detect which toolchain it's being invoked from and then run the set substitute-path path with the appropriate paths. I'm willing to help mentor someone in fixing this
Hi, I'm looking for a first issue, would love the mentoring!
can't reproduce it, it works just fine nearly 4 yrs later, has this perhaps already been fixed ?
Past should have included a sample test case.
No, I can still reproduce it. are you maybe using a distro-packaged toolchain? Crashing program: output: To make work, don't use in the replacement.


Question: initial_res: Option<Res>, res: Res| { if let Some(initial_res) = initial_res { <del> if res != initial_res && res != Res::Err && this.ambiguity_errors.is_empty() { </del> <ins> if res != initial_res { </ins> // Make sure compilation does not succeed if preferred macro resolution // has changed after the macro had been expanded. In theory all such <del> // situations should be reported as ambiguity errors, so this is a bug. span_bug!(span, "inconsistent resolution for a macro"); </del> <ins> // situations should be reported as errors, so this is a bug. this.session.delay_span_bug(span, "inconsistent resolution for a macro"); </ins> } } else { // It's possible that the macro was unresolved (indeterminate) and silently

<!-- 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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Seems to have regressed in Rust 1.33 based on testing in Godbolt.
With only the errors relevant to the ICE:
I'll fix this.
Fixed in


Question: <ins> // aux-build:drop-shim-relates-opaque-aux.rs // compile-flags: -Zvalidate-mir --crate-type=lib // build-pass extern crate drop_shim_relates_opaque_aux; pub fn drop_foo(_: drop_shim_relates_opaque_aux::Foo) {} pub fn drop_bar(_: drop_shim_relates_opaque_aux::Bar) {} fn main() {} </ins>

<!-- 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. --: Not posting the entire 1.7K lines backtrace :upsidedownface: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
You can also reproduce this in the rustc repo itself where will encounter the error with
Reduced: label F-typealiasimpl_trait
Found another repro I think: this one bisects to
`
prioritize
going to also link and as other reports of the same issue
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Ok, after a bit more back ond forth , I'm tentatively bumping this issue to P-critical and raise these questions (echoing the comments from the discussion): would it make sense to revert ? cc or would it make sense to revert (which IIUC leaked in the std library an unstable nightly only feature) ? cc Next week Rust 1.72 will be released, artifacts are going to be build real soon, I think. Thanks for additional comments to help improve my understanding of the context here. label -P-medium +P-critical
The underlying issue here is an issue with TAIT. was an implementation-only change simplifying some backtrace code in that was made under the assumption that TAIT was reliable enough to be used inside . As it is not user-facing it should be easily revertible. So the question here is whether it is safer to get TAIT working (potentially by reverting ?) so it can be used internally or to just hold off on using it until the issue has been resolved, reapplying once that happens. I have no compiler experience, but my initial hunch would be that the library change is preferable for now. I'll get a PR ready until tomorrow, unless someone beats me to it.
should not be reverted.


Question: <ins> // aux-build:drop-shim-relates-opaque-aux.rs // compile-flags: -Zvalidate-mir --crate-type=lib // build-pass extern crate drop_shim_relates_opaque_aux; pub fn drop_foo(_: drop_shim_relates_opaque_aux::Foo) {} pub fn drop_bar(_: drop_shim_relates_opaque_aux::Bar) {} fn main() {} </ins>

All it does is cause us to now eagerly reveal opaques that were being skipped over during normalization, which means that we're just not hitting this code anymore: It does not introduce a bug, it just reveals one that already existed. I'm gonna use the minimized example () here. What's happening here is that we're generating a drop shim for that looks like: which then tries to validate that . However, it has type , where is a , which does not hit the code I linked above. Before , we'd emit something that looks like: which is a field that is incompletely normalized, but does* hit the code above.
Submitted the PR reverting : .
fixes this issue by not considering mir validity on shims until they have been optimized, which uses the reveal-all param-env for that shim. This ICE shouldn't be possible to trigger without , since it has to do with one of the intra-pass mir validations that are only done when that flag is active: I don't personally think that needs to be reverted, either.
This was also possible to trigger even before using an associated type. The test in exercises this too.


Question: <ins> // compile-flags:--test /// A check of using various process termination strategies /// /// # Examples /// /// ```rust /// assert!(true); // this returns `()`, all is well /// ``` /// /// You can also simply return `Ok(())`, but you'll need to disambiguate the /// type using turbofish, because we cannot infer the type: /// /// ```rust /// Ok::<(), &'static str>(()) /// ``` /// /// You can err with anything that implements `Debug`: /// /// ```rust,should_panic /// Err("This is returned from `main`, leading to panic")?; /// Ok::<(), &'static str>(()) /// ``` pub fn check_process_termination() {} </ins>

Rustdoc now allows us to use in our tests. Unfortunately, this requires writing the manually, which really shouldn't be needed IMHO. So we now have to write: rust ///# fn main() -Result<(), (){ /// let foo = Ok(1usize); /// assert!(foo? 0); ///# } /// where it should suffice to write: rust /// let foo = Ok(1usize); /// assert!(foo? 0); /// Doing so will make the tests shorter and hopefully lead to more and less in tests.
Feels like a no-brainer to me; would be great. :)
I think there are two things we want before doing this: , so that it can always be , and existing code will just work. The re-do, so we can make a type that accepts any error type (since it'll just error anyway).
?
Yes, that's what I'm thinking, and I'm setting up a PR for that. However, it's still unstable.
I talked about this back in March on the " in main" tracking issue: That sample you gave isn't even valid as-is, unless coercing to is also in the pipeline?
That'll be next, hopefully. I wonder if it suffices to or if we need to keep a generic error type (which might mess with type inference). In any event, having both the aforementioned and should be a no-brainer, right?


Question: <ins> #![feature(return_position_impl_trait_in_trait)] trait Iterable { type Item<'a> where Self: 'a; fn iter(&self) -> impl Iterator<Item = Self::Item<'missing>>; //~^ ERROR use of undeclared lifetime name `'missing` } fn main() {} </ins>

<!-- 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


Question: out_filenames.push(out_filename); } <ins> if sess.opts.cg.save_temps { let _ = tmpdir.into_path(); } </ins> out_filenames }

Tagging as E-easy and E-mentor. The fix here involves changing the code to call to prevent the temp dir from destroying itself. This should be wrapped in an if like this one:
Hi, I want to try working on this.
Go ahead! Let me know if you need any assistance - feel free to either reach out here or over IRC (simulacrum is my handle there).


Question: passes.into_iter().collect(), css_file_extension, renderinfo, <del> render_type) </del> <ins> render_type, sort_modules_alphabetically) </ins> .expect("failed to generate documentation"); 0 }

Instead it should use the order that appear in the crate file. Even better, it should allow adding section headers (with a description) between them. Hypothetically: And get something like this: This would make both the source code and the documentation more accessible as the modules would be presented in a comprehensible order, with some description of each related group of modules. Edit: Rename issue to reflect that this isn't an either-or. Alphabetical order is useful, but so is programmer-specified order (to make the code accessible for newcomers) and Rustdoc should support both - see the thread below.
Shouldn't related modules be nested in submodules rather than logically ordered in the source? Finding things in long non-ordered lists is a real pain.
Yeah, I'm going to vote "alphabetical".
Hmmm. I pretty sure I put a comment here, and now its gone. Strange. Anyway. Here it goes again. Alphabetical order == random order. That's great when you know what you are looking for and just want to find it. When coming to a new non-trivial code base, being presented the content in random order is just about the worst possible way to access it. Nested modules allow us to group related modules together, and that's a good thing. If you have a long list of modules, certainly, group them. But this doesn't solve the problem. You now have a TOC where each level is randomized, which is still inaccessible. Searching for a function or module by name is an important use case, sure. But being able to access a new code base is as important, if not more so. Looking up a name in a short non-alphabetized list (at each level) isn't too hard, and one can always compensate for the lack of an alphabetical index by using ^F. Trying to understand a system presented in random order is next to impossible, and one can not compensate for the lack of a comprehensible order in a large system. If there was a way to specify the order of the entries in each level, which we agree should only contain "a few" entries, then the TOC would become accessible. If one could even add a bit of annotation for each level, so much the better.


Question: passes.into_iter().collect(), css_file_extension, renderinfo, <del> render_type) </del> <ins> render_type, sort_modules_alphabetically) </ins> .expect("failed to generate documentation"); 0 }

The annotated TOC would serve as a very accessible way for a newcomer to understand the code base. And, this doesn't rule out also generating an alphabetically sorted reference index, beside the TOC. All good books do both - a TOC in reasonable order and an index for looking up data by name. We shouldn't have to choose, we should be able to get both. So, I misnamed the issue. It should be "Rustdoc shouldn't list modules only alphabetically".
Agreed. Can someone rename the title?
Rename done.
Visiting for triage. Minor, but still an issue.
Triage, still listed alphabetically. Here's a sample source file: !


Question: "clippy_lints", "compiletest_rs", "derive-new", <ins> "git2", </ins> "lazy_static 1.3.0", "regex", "rustc-workspace-hack", "rustc_tools_util 0.2.0", "semver", "serde", <ins> "tempfile", </ins> "tester", ]

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! cc the PR reviewer, and nominating for compiler team prioritization.


Question: use crate::fluent_generated as fluent; use crate::parser; <ins> use crate::parser::attr::InnerAttrPolicy; </ins> use rustc_ast as ast; use rustc_ast::ptr::P; use rustc_ast::token::{self, Delimiter, Lit, LitKind, TokenKind};

Error code: Metadata:
What is the issue you are reporting here ?
Well, I thought that compiler can understand that is related to the block of code, but it fails.
Can you post a minimal reproducible example that demonstrates your issue? Or at least mention exactly what you'd expect to happen and why. Even code that is cfged out is still required to parse successfully.
Let's show you what exactly problem I have. Full code: And I get this error:
You seem to already have posted this a month ago. What you're asking seems a rather big change to me, I'm not that familiar with how the compiler parser works but I believe it currently requires your program syntax to be correct before macros are expanded, which is not true for your example, so some fundamental changes would be needed.
Oh, damn, sorry. I totally forgot that I made a post. Well, if it's not a bug and parser works like this it is bad, anyway, exists alternative way to write like this. But for me my issue is a candidate to feature request or a bug. Anyway, I'm not a lang dev, so I don't know what scales of this defect (?).
The workaround for this is to wrap the expressions in a block:
I solved this issue exactly as you did.
Another way to do this is using the macro and . I personally thinks it is more clear, and should optimize the same.
Work is not the same, due to compile-time evaluating an expression that we pass in it and evaluates only it, but at the same time everything compiles what is inside of .


Question: <ins> error[E0599]: no function or associated item named `mew` found for struct `Vec<Q>` in the current scope --> $DIR/bad-builder.rs:2:15 | LL |     Vec::<Q>::mew() |               ^^^ |               | |               function or associated item not found in `Vec<Q>` |               help: there is an associated function with a similar name: `new` | note: if you're trying to build a new `Vec<Q>` consider using one of the following associated functions: Vec::<T>::new Vec::<T>::with_capacity Vec::<T>::from_raw_parts Vec::<T, A>::new_in and 2 others --> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0599`. </ins>

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'', 'thread 'rustc' panicked at 'assertion failed: param types with same index differ in name'' File: --auto-reduced (treereduce-rust): original: Version information ` Command:
thanks for the stack trace for this class of ICEs, it's just the right thing that I need. Minimal:


Question: <ins> #![allow(incomplete_features)] #![feature(generic_const_exprs)] #![feature(trait_alias)] trait Bar<const N: usize> {} trait BB = Bar<{ 2 + 1 }>; fn foo(x: &dyn BB) {} //~^ ERROR the trait alias `BB` cannot be made into an object [E0038] fn main() {} </ins>

<!-- 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
This was likely introduced in (CC rustc 1.65 nightly 2022-08-12 emits the following:


Question: <ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub trait Trait<const N: usize>: From<<Self as Trait<N>>::Item> { type Item; } fn main() {} </ins>

results in an ICE (): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: <ins> error: `start` language item function is not allowed to have `#[target_feature]` --> $DIR/start_lang_item_with_target_feature.rs:13:1 | LL | #[target_feature(enable = "avx2")] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL | LL | fn start<T>(_main: fn() -> T, _argc: isize, _argv: *const *const u8, _sigpipe: u8) -> isize { | ------------------------------------------------------------------------------------------- `start` language item function is not allowed to have `#[target_feature]` error: aborting due to previous error </ins>

This works (but it shouldn't): similar to , cc (tracking issue) label T-lang T-compiler C-bug I-unsound F-targetfeature11
cc , author of Note that this is about the nostd panic handler, not about the function. This fails as it should: gives
ugh we really need a way to make sure that every single "this is called by rust" function gets a check... I assume that these functions can't be unsafe, so I guess those checks are a food way to start looking and make sure to deduplicate the logic there?
Yeah sadly we do need to make sure, not just for the constructs that we have now but also it needs to be kept in mind for the future constructs we add or stabilize. A lot thankfully goes through either the trait system (operators or the GlobalAlloc trait used by ) or function pointers (alloc error hook, std panic hook). Functions that you can make callable solely by setting an attribute, those are rare. The best list of lang items I could find was in the , so that would be a great start for such an exhaustive search. Thankfully most of them are unstable, but still it needs to be addressed for each of them before stabilization (if that is a target).
WG-prioritization assigning priority (). label -I-prioritize +P-medium
label +requires-nightly
There is also another table of lang items in the source code, .