#75443 may have also allowed some other code to now successfully compile which would make this revert a breaking change after 2 stable versions, but I hope that this is a purely theoretical concern.

Can you say more about this? Maybe a code example if possible? I think if we are to land a breaking change I'd prefer to have pre-prepared a note to include in the release notes, at least.

Full builds are basically unaffected, and wall times do not see major impacts either. I think this is fine from a performance perspective: performance is important, but this is a correctness fix, and that can sometimes (of course) carry performance hazards with it.

That said, it looks like this carries a bunch of commits after the first one which (at first glance) look unrelated, perhaps they need to be rebased into a separate PR?

We discussed this in the T-lang meeting today, and though no specific objections to stabilization were discussed, I did have the concern that this feels like it either:

• does the wrong thing in practice (i.e., does not match libcore's atomic types existing)
• does precisely the same thing as cfg(accessible) would, in which case this is not particularly useful and seems like not something we should stabilize.

We did not reach any firm conclusions, but my feeling was that we were interested in putting time into cfg accessible rather than into this issue in particular.

That said, if I was wrong in the assumption that this is a 1:1 with cfg(accessible), then we should discuss further.

Removing nomination for now.

https://github.com/rust-lang/rust/issues/78143 is almost certain to be closed as won't fix, so should be included in compat notes here.

I will try to work out an implementation to better get a sense of what would fall out of the impl naturally without too much contortion. We'll then try to FCP that proposal.

(If this ends up taking too long, we will likely just revert #77534 on beta or so; I am not too worried, as it is not yet a beta regression).

cc @jyn514

Are you self-bootstrapping the cross build (setting rustc/cargo 1.47 as well)? I guess that's the only difference I can think of that would obviously cause things like this.

It's also possible this is just always broken, rust-lang/rust doesn't cross-compile documentation I think for most platforms so we don't really test it.

Since this adds code, I suspect it's always going to be a regression. I would ignore the incremental benchmarks here, which brings us down to roughly 5% regression on real world codebases. I think given this is a soundness fix (at least arguably) and certainly unintuitive behavior, we should land this (modulo review of the diff itself, which I have not done).

Hm, I think there's a only-hosts comment you can put to achieve the same thing.

I think I've personally been slowly more convinced over time that this is probably the right thing to do if we can pull it off on benchmarks and such (seems not implausible, given existing allocations etc) -- I think the right next step is to kick off some discussion on internals.rust-lang.org and get a read on how libs team feels about this (#t-libs on Zulip is probably best for that). See also https://github.com/rust-lang/rfcs/pull/2979, which tries to codify some of these processes :)

Ah, hm. Well -- at least currently, the llvm-8 builder does not have debug asserts enabled. I think this test can also be a regular (non-fulldeps) run-make test. Maybe we want to explicitly mark that builder as disabling debug assertions, editing the comment in https://github.com/rust-lang/rust/blob/b6ac411f45d38d867ce9f689bbd5c3e7456d0f65/src/ci/docker/host-x86_64/x86_64-gnu-llvm-8/Dockerfile#L61-L65? Obviously not full coverage, but for this I don't think we really need it.

For codegen and run-make tests (i.e., not full deps tests) it should also be relatively quick to build a non-debug-assert enabled std in rustbuild just for them, though that's really not supported right now so we'd need some fairly annoying option threading to make that happen.

I'd personally also be fine disabling std debug asserts on the nopt builders or something like that -- that would give us more coverage as well...

@bors r+ rollup=never p=5

I think @kinnison had indicated as such initially? It seems like that'll need a rustup release.

cc @XAMPPRocky as well since I think this might need to get dropped from relnotes for now in that case, I sort of doubt we'll have a rustup release in the next 3ish weeks

Also, I'm now thinking it would be better to stop using the Root alias at the node level and move it up to the map level.

Hm, I'm not sure I quite follow, but I think this feels wrong -- roots are useful when e.g. splitting out a subtree which will later be joined in a different place. I'm not sure that the code will care too much about this distinction though.

@bors r+ rollup=never

Can you clarify exactly what leaks and where? I'm not sure I'm quite following -- it might be a bug with drop elaboration or something like that if I am, in which case we shouldn't fix it here.

Always true:

• Behavior of attributes is order-dependent, last attribute wins. Duplicate (e.g., #![deny(unused)] ... #![deny(unused)] attributes are not an error.
• cap-lints always overrides any level set, including forbid.
• It is an error to attempt to lower the level from forbid when in nested scopes (e.g., CLI says forbid, code says deny at top level). At the same scope this is not an error. Note that for modules, the outer and inner scopes can be in different files (#[attr] mod foo; and foo.rs has #![attr]).

New behavior, introduced by https://github.com/rust-lang/rust/pull/77534:

Forbid (essentially) takes immediate effect, rather than being overridden by other attributes at the same level. This is unique behavior specifically to forbid; no other lint receives the same treatment.

I would propose the following (the implementation should be worked out, of course, but this seems feasible -- I would not FCP until we have a PR, just that if people have objections to this raising them now seems good):

• Warn (unused attribute) on skipped/ignored attributes at the same level.
  • This is not an error for backwards compatibility, primarily.
  • One downside is that this is basically not possible to silence in a targeted fashion (you have to disable it for a whole tree, but that's probably not too important -- in practice this is true of all attribute lints).
• Locally overriding forbid (i.e., at different or the same level) is a forbid-by-default lint. This means you can't disable it except with cap-lints.
  • This also matches just the behavior of forbid itself which seems quite reasonable.
  • This is backwards compatible in dependencies, though not locally. I think the breakage for forbid followed by an allow/deny whatever at the same level is likely to be minimal, and desirable. If we choose not to do this it would hopefully be caught by the first bullet here, but I suspect that one will not be as easy to implement.

Oh, looks like CI is failing here:

tidy error: /checkout/src/test/ui/issues/issue-75763.rs:7: trailing whitespace

@bors r-

(r=me with that fixed though)

I think closing #75673 is likely fine -- the broader issue of whether invalid UTF-8 in const generic &str should be caught during transmutes is something to settle before stabilization of str in consts. (It is unclear to me that we indeed must prohibit such a thing, as indicated on said issue). cc @lcnr just in case though

@bors r+

cc https://github.com/rust-lang/rust/issues/54114, which may be the same underlying bug (but pre-existing?)

I'm re-adding the MCVE label because the crate on beta does not require features, so we should be able to come up with a non-nightly MCVE.

@the8472 fwiw, on future PRs, especially if rebasing it would be great to squash out commits that are fixups (e.g., tidy fixes) and such to have a cleaner git history.

Any LLVM submodule update landing means that we can switch rust-dev downloads added by #76349 to look for the LLVM submodule update rather than latest bors commit. That'll avoid spuriously redownloading essentially identical tarballs whenever someone rebases.

This is technically a QoL issue so does not block that PR, but is a rather major improvement since rebasing is quite common and the download is relatively hefty at ~20 MB.

I believe this has since been fixed, so closing.

@bors r+

@bors try

I generally ask that such PRs also bump the libc dep in a Cargo.toml somewhere in the workspace, so we don't accidentally regress in a future PR when rebasing across this change (I've done it before myself, and only noticed when looking at the diff, which for larger Cargo.lock changes is a bit untenable). r=me with that done.

This time around wall times are down roughly 50%. So either this PR considerably increases the amount of noise we see (seems highly unlikely) or something has landed in the meantime that shifts things around to this being a net improvement now. Regardless cycles and instructions seem neutral or down, and since llvm-mca points at throughput increases, I think we should merge this.

@bors r+

I would also like to see the increased mem::uninitialized runtime checking change featured in the compatibility notes -- https://github.com/rust-lang/rust/pull/71274 -- potentially quite a few users are likely to encounter the asserts added by that PR (which is fine, their code is currently UB so I'd rather they get asserts rather than silent miscompiles), we should add a pointer to the notes for them.

cc @rust-lang/project-portable-simd (perhaps?)

I'm going to r? @KodrAus here though in the hopes that you're more familiar or can direct this to an appropriate reviewer

r=me though on the change itself (I think I approved a similar commit elsewhere, IIRC a bit smaller but I might be misremembering)

Oh, hm, I did not see this before that other PR. If you want to ping me on Zulip to just say "please review in this order" or whatever, that's fine by me -- otherwise I usually go in oldest first order in my waiting-on-review queue.

Please drop the non-freebsd job from the try builder in the future. The CI changes otherwise look reasonable here, but I cannot try this PR because of the conflict.

Please also squash commits. I'll want to do another read through I think, but I suspect this is good to go modulo the nit.

This is presumably meant to be profiler_enabled?

I'm going to r? @m-ou-se here, I'm not sure what the right path is -- would need to think about it -- but you seem to have a better handle on it than I :)

FWIW "Additionally tidies touched test files." is probably a bad idea in the future -- it adds blame noise for future lookers (though not so important in tests), at the very least, and also makes reviewers need to pay even more attention to slight details. In this case though there's not too many files that I minded doing so, so no worries.

@bors r+ rollup

@bors r+ rollup

Based on Niko's last comment on #57642, it sounds like the second case might not be something we actually want to reject, but since it matches non-NLL behavior I think we should test for it and we can adjust the test consciously in the future if necessary.

@bors r+

Hm, so when you ask "Ideally, we'd apply this to every crate that isn't a proc macro or compiled into a dynamically linkable version of std. How can we most easily capture that set here?" -- do you mean to do that as an end-user visible change (rather than just to crates compiled by rustbuild? It seems to me that rustc shouldn't really be special here in some sense. That's probably not quite true because we have the somewhat odd case of compiling to dylibs that aren't intended to be dlopen'd (rather just linked directly), but I'm not sure that's important.

I think the best thing is probably to start out with just a change to how we compile rustc which should be somewhat easier to land and see impacts of though. To do so we probably want to set the -Z flag via rustflags if possible, something like this diff. This will set it for pretty much everything except std workspace and crates that don't get rustflags (e.g., proc macros and other build deps). Note that this includes e.g. cargo and clippy too, but I think that's the right thing?

diff --git a/src/bootstrap/builder.rs b/src/bootstrap/builder.rs
index 707c1ff3efa..0f6a74b01ce 100644
--- a/src/bootstrap/builder.rs
+++ b/src/bootstrap/builder.rs
@@ -1114,6 +1114,10 @@ impl<'a> Builder<'a> {
             }
         }
 
+        if mode != Mode::Std {
+            rustflags.arg("-Ztls-model=initial-exec");
+        }
+
         if self.config.incremental {
             cargo.env("CARGO_INCREMENTAL", "1");
         } else {

nit: double 8-8 here.

I've looked for errors in bootstrap.py by adding type hints and running mypy over it. Untyped python code often tends to have some hidden problems. I haven't found any bugs, only some quality problems in that the RustBuild class is a bit of a god class and it's hard to follow what's initialized when and where.

It may be worth it to keep the type annotations as they also act as documentation. A couple of variables have rather surprising types. I could also add mypy to CI, but I'd understand if you don't want to raise the requirements for Python specific tooling.

I'm going to go ahead and close this because I don't think we'd want to merge this right now. I'm not sure that we'd ever want to do this without CI checking, and I think it's just too high a burden to do so in general for the relatively short Python script we have.

It should be possible to disable the test if debug asserts are enabled (I forget the syntax or whether it's supported though). I can search for that during my next review pass if you set this to waiting on reviewer.

@bors r+

Thanks!

I agree that a 50% wall time regression is likely to be mostly noise - unfortunately we don't really have a good way yet of determining noise on the presentation layer such that we could hide deltas within the noise bound and then (hopefully) show all the statistics we collect in some way.

That said, I am inclined to land this as is presuming this perf run comes back similarly (or better). I think most of the wall time regressions are on tiny crates - several milliseconds - and so aren't too interesting.

@bors r+ rollup

I've also asked GitHub about the reordering.

@bors r+

@bors r+

I feel like this is ambiguous whether this is actually providing an example of "good" or "bad" code. Maybe we can adjust the wording to be clearer, or just not providing a code example here is fine -- we don't want to recommend the pattern after all :)

@bors r+ rollup=never

I am a bit worried this is going to cause ICEs somewhere, but it shouldn't be in dist artifacts so I'm not too worried. We can deal with it if it comes up.

@bors r+ rollup

Thanks, I agree this is better.

r=me with commits squashed

Niko indicated that the flip in coercion order was likely fine during the last meeting -- @estebank, would you be up for squashing the commits here a bit? Ideally I'd prefer to avoid 4 commits for such a small and dense change :)

r=me though.

The perf results here don't seem to really correspond nicely to the conclusions laid out in the PR description: wall times contain a bunch of regressions, and the instruction counts are slightly up as well. Maybe LLVM 11 (which I think landed since then) changed the calculus for the compiler, though -- let's generate another round of benchmarks.

@bors try @rust-timer queue

@nagisa Do the perf results match your expectations? @joshtriplett -- I think you didn't comment on them at all, perhaps you have thoughts?

Generally speaking I'm fine with landing this -- the implementation looks correct -- but it seems like if it's a regression on rustc runtime then maybe we shouldn't?

@bors r+ rollup

Which ones did we miss (it would be good to at least add it on master now)? Also, it looks like the PR linked here modifies RefCell, not Cell, which doesn't panic.

- [Fixed recursive nonterminals not being expanded in macros during

I read this as expanding the set from length <= 32 to all, but it looks like it's just all arrays... I would be interested if you have thoughts on how to clarify that, but ultimately I don't think it's important so fine to just resolve.

I think this isn't quite right -- what has changed is that const fn will no longer get implicitly promoted, I think? i.e., &foo() where foo is a const fn and the type is requested at &'static T will no longer compile on beta.

cc @rust-lang/wg-const-eval is there a succinct summary we could include here? Maybe we can get someone to put together a short inside rust blog post we can link to here?

I would prefer to avoid putting these URLs in PR bodies if we don't automatically strip them out when adding the PR to the commit log. Maybe we could add that filtering? See e.g. #100 for an example of such.

That said I'd want feedback from people doing rollups on the regular if this is a good solution -- cc @RalfJung @dylan-dpc @jonas-schievink (we really need a pingable team here)

@bors r+

@jyn514 to check in, do you think you'd be interested in implementing the solution I suggested above?

That would make sense to me; that said, for CI and other environments that want all targets to have this it'll be much easier to have the global option around too. I would likely accept a PR for this if the implementation can be localized to configuration parsing (and maybe slight alterations of how we query for sanitizer/profiler enablement).

We don't currently record self profile data for rustc compilation.

I would not look at incremental benchmarks on PRs like this - they're not likely to be super meaningful as an expression of improvement (or regression) because they are skipping parts of the build, and unless we think this optimization permits skipping more (seems unlikely), the percent win there is just larger because the base is smaller.

It looks like this is about a 1% win in practice instruction counts wise, but appears to be a regression on wall times (e.g. rustc middle regressed roughly 2 seconds, it looks like).

I think we are least don't have solid evidence this is a win on the code examples tested by perf. I'm not sure if perhaps switching algorithms when we detect n > 30 or something like that makes sense?

Nominating for lang team, I suspect we'll want to just let this go through (it's not really breaking) but it's an interesting question of whether these documentation comments are truly unused.

EFS is shared between the (potentially multiple) instances of bors which are running, and in general the git lockfile can get left spuriously behind (e.g., if we end up aborting not-nicely). The rust repository is not that big especially without submodules too.

Probably we want to call it rustc-subtree then, or something like that. Doesn't seem like a huge concern -- people interacting with it are a relatively small set, hopefully.

Thanks! I think this is still good to merge (we might want to adjust the 3 buffer taking function to be private since it seems likely useless now, though I'd prefer to do that in a separate PR).

Seems fine as is