Fix Box allocator drop elaboration
New version of rust-lang/rust#131146.
Clearing Box's drop flag after running its destructor can cause it to skip dropping its allocator, so just don't. Its cleared by the drop ladder code afterwards already.
Unlike the last PR this also handles other types with destructors properly, in the event that we can have open drops on them in the future (by partial initialization or DerefMove or something).
Finally, I also added tests for the interaction with async drop here but I discovered rust-lang/rust#143658, so one of the tests has a `knownbug` annotation. Not sure if it should be in this PR at all though.
Fixesrust-lang/rust#131082
r? wesleywiser - prev. reviewer
uniquify root goals during HIR typeck
We need to rely on region identity to deal with hangs such as https://github.com/rust-lang/trait-system-refactor-initiative/issues/210 and to keep the current behavior of `fn try_merge_responses`.
This is a problem as borrowck starts by replacing each *occurrence* of a region with a unique inference variable. This frequently splits a single region during HIR typeck into multiple distinct regions. As we assume goals to always succeed during borrowck, relying on two occurances of a region being identical during HIR typeck causes ICE. See the now fixed examples in https://github.com/rust-lang/trait-system-refactor-initiative/issues/27 and rust-lang/rust#139409.
We've previously tried to avoid this issue by always *uniquifying* regions when canonicalizing goals. This prevents caching subtrees during canonicalization which resulted in hangs for very large types. People rely on such types in practice, which caused us to revert our attempt to reinstate `#[type_length_limit]` in https://github.com/rust-lang/rust/pull/127670. The complete list of changes here:
- rust-lang/rust#107981
- rust-lang/rust#110180
- rust-lang/rust#114117
- rust-lang/rust#130821
After more consideration, all occurrences of such large types need to happen outside of typeck/borrowck. We know this as we already walk over all types in the MIR body when replacing their regions with nll vars.
This PR therefore enables us to rely on region identity inside of the trait solver by exclusively **uniquifying root goals during HIR typeck**. These are the only goals we assume to hold during borrowck. This is insufficient as type inference variables may "hide" regions we later uniquify. Because of this, we now stash proven goals which depend on inference variables in HIR typeck and reprove them after writeback. This closes https://github.com/rust-lang/trait-system-refactor-initiative/issues/127.
This was originally part of rust-lang/rust#144258 but I've moved it into a separate PR. While I believe we need to rely on region identity to fix the performance issues in some way, I don't know whether rust-lang/rust#144258 is the best approach to actually do so. Regardless of how we deal with the hangs however, this change is necessary and desirable regardless.
r? `@compiler-errors` or `@BoxyUwU`
Remove eval_always from check_private_in_public.
This PR attempts to avoid re-computing `check_private_in_public` query. First by marking the query as non-`eval_always`, and by reducing the amount of accesses to HIR as much as possible.
Latest perf https://github.com/rust-lang/rust/pull/116316#issuecomment-3094672105 shows that we manage it. The cost is extra dep-graph bookkeeping.
Reject running `compiletest` self-tests against stage 0 rustc unless explicitly allowed
Currently, in `pr-check-1`, we run `python3 ../x.py test --stage 0 src/tools/compiletest`, which is `compiletest` self-tests against stage 0 rustc. This makes it very annoying for PRs wanting to change target spec JSON format, which `compiletest` depends on for target information, as otherwise `compiletest` would have to know how to handle 2 different target spec JSON formats and know when to pick which.
Instead of doing that, we change `compiletest` self-tests to reject running against stage 0 `rustc` *unless* explicitly allowed with `build.compiletest-allow-stage0=true`. `build.compiletest-allow-stage0` is a proper bootstrap config option in favor of the ad-hoc `COMPILETEST_FORCE_STAGE0` env var. This means that:
- `./x test src/tools/compiletest --stage=0` is not allowed, unless `build.compiletest-allow-stage0=true` is set. In this scenario, `compiletest` self-tests should be expected to fail unless the stage 0 `rustc` as provided is like codegen_cranelift where it's *actually* built from in-tree `rustc` sources.
- In CI, we change `./x test src/tools/compiletest --stage=0` to `./x test src/tools/compiletest --stage=1`, and move it to `pr-check-2`. Yes, this involves building the stage 1 compiler, but `pr-check-2` already has to build stage 1 compiler to test stage 1 library crates.
- Crucially, this means that **`compiletest` is only intended to support one target spec JSON format**, namely the one corresponding to the in-tree `rustc`.
- This should preserve the `compiletest-use-stage0-libtest` UX optimization where changing `compiler/` tree should still not require rebuilding `compiletest` as long as `build.compiletest-use-stage0-libtest=true`, as that should remain orthogonal. This is completely unlike my previous attempt at https://github.com/rust-lang/rust/pull/144563 that tries to do a way more invasive change which would cause the rebuild problem.
Best reviewed commit-by-commit.
---
r? `@Kobzol`
clean up codegen fn attrs
This honestly had become a mess over time and needed some love. No behavior should've changed, and I effectively just moved code around. Though, I can't promise there weren't any bugs in the original code with how randomly it was organised.....
r? `@WaffleLapkin`
Support multiple crate versions in --extern-html-root-url
Rustdoc's `--extern-html-root-url` used to use `tcx.crate_name()` to identify crates, but that used crates' internal names from their metadata, instead of names given to them in `--extern`. That was confusing, because both `--extern…` arguments seem related and use similar syntax. Crucially, this didn't work correctly with Cargo's package aliases or multiple versions of crates.
`sess.opts.externs` lacks `CrateNum`, and `Resolver.extern_prelude` gets destroyed before `rustdoc` has a chance to see it, so I've had to save this mapping in `CStore`.
Just in case, I've kept the previous mapping by crate name as a fallback for crates that weren't matched by their extern name.
Fixesrust-lang/rust#76296
Add method `find_ancestor_not_from_macro` and `find_ancestor_not_from_extern_macro` to supersede `find_oldest_ancestor_in_same_ctxt`
As I was using it, I realized that the function is supposed to walk up to expand the chain? This seems to be the opposite of what I understood.
r? `@jieyouxu`
Add support for the m68k architecture in 'object_architecture'
This is a tiny PR that adds the m68k architecture to `object_architecture`. This allows us to build rmeta files for that ISA(we use the object crate to pack metadata into object files).
expand: Micro-optimize prelude injection
Use `splice` to avoid shifting the other items twice.
Put `extern crate std;` first so it's already resolved when we resolve `::std::prelude::rust_20XX`.
coverage: Treat `#[automatically_derived]` as `#[coverage(off)]`
One of the contributing factors behind https://github.com/rust-lang/rust/issues/141577#issuecomment-3120667286 was the presence of derive-macro-generated code containing nested closures.
Coverage instrumentation already has a heuristic for skipping code marked with `#[automatically_derived]` (rust-lang/rust#120185), because derived code is usually not worth instrumenting, and also has a tendency to trigger vexing edge-case bugs in coverage instrumentation or coverage codegen.
However, the existing heuristic only applied to the associated items directly within an auto-derived impl block, and had no effect on closures or nested items within those associated items.
This PR therefore extends the search for `#[coverage(..)]` attributes to also treat `#[automatically_derived]` as an implied `#[coverage(off)]` for the purposes of coverage instrumentation.
---
This change doesn’t rule out an entire category of bugs, because it only affects code that actually uses the auto-derived attribute. But it should reduce the overall chance of edge-case macro span bugs being observed in the wild.
Stuart Cook