Add `ToolTarget` to bootstrap
Oh, you thought I'm done with refactoring bootstrap tools? Na-ah, think again! After the failure of https://github.com/rust-lang/rust/pull/143581, `ToolTarget` is back with a vengeance. This time, I implemented the test changes and tool cleanups without forcing these tools to be built with the stage0 compiler.
There are still some small wins though, `LlvmBitcodeLinker` now starts at stage 1, and not stage 2. Cargo should also be ported to this new mode, but I'm leaving that for a follow-up PR.
Hopefully X-th time's the charm 🤞
r? `@jieyouxu`
Simplify discriminant codegen for niche-encoded variants which don't wrap across an integer boundary
Inspired by rust-lang/rust#139729, this attempts to be a much-simpler and more-localized change while still making a difference. (Specifically, this does not try to solve the problem with select-sinking, leaving that to be fixed by https://github.com/llvm/llvm-project/issues/134024 -- once it gets released -- instead of in rustc's codegen.)
What this *does* improve is checking for the variant in a 3+ variant enum when that variant is the type providing the niche. Something like `if let Foo::WithBool(_) = ...` previously compiled to `ugt(add(x, -2), 2)`, which is non-trivial to think about because it's depending on the unsigned wrapping to shift the 0/1 up above 2. With this PR it compiles to just `ult(x, 2)`, which is probably what you'd have written yourself if you were doing it by hand to look for "is this byte a bool?".
That's done by leaving most of the codegen alone, but adding a couple new special cases to the `is_niche` check. The default looks at the relative discriminant, but in the common cases where there's no wraparound involved, we can just check the original value, rather than the offsetted one.
The first commit just adds some tests, so the best way to see the effect of this change is to look at the second commit and how it updates the test expectations.
Ignore tests/run-make/link-eh-frame-terminator/rmake.rs when cross-compiling
The test tests/run-make/link-eh-frame-terminator/rmake.rs fails to link when cross-compiling. Therefore, it should be ignored in cross-compilation environments.
See [commit a27bdea](a27bdea4b7) and [commit 2beccc4](2beccc4d8e) for reference.
Rename `emit_unless` to `emit_unless_delay`
`emit_unless` is very unintuitive and confusing. The first impression is as if it will only emit if the parameter is true, without the altnative "delay as a bug".
`emit_unless_delay` expresses two things:
1. emit unless the `delay` parameter is true
2. either *emit immediately* or *delay as bug*
r? `@compiler-errors`
bootstrap: Detect musl hosts
Currently, all non-Android Linux hosts are assumed to be using glibc. This obviously isn't very portable and will currently result in downloading a stage0 toolchain for glibc even on musl hosts.
There are multiple ways to detect musl somewhat reliably, but the easiest option is to check for the python target, which is exposed in `sys.implementation._multiarch` and has values like "x86_64-linux-gnu" or "powerpc64le-linux-musl".
Don't test panic=unwind in panic_main.rs on Fuchsia
````@Enselic```` added a few new test conditions to tests/ui/panics/panic-main.rs in rust-lang/rust#142304, but it is unfortunately causing the test to fail for Fuchsia with the `panic=unwind` modes since we compile Rust for Fuchsia with `panic=abort`. This patch just ignores the test for Fuchsia.
Note that this test might also need to filter out a few other platforms, since another panicking test we exclude from Fuchsia https://github.com/rust-lang/rust/blob/master/tests/ui/panics/runtime-switch.rs also excludes running on msvc, android, openbsd, and wasm, but I'm not familiar with those platforms so I didn't want to add them here.
cc ````@compile-errors,```` who reviewed the initial PR
Be a bit more careful around exotic cycles in in the inliner
Copied from the comment here: https://github.com/rust-lang/rust/issues/143700#issuecomment-3053810353
---
```rust
#![feature(fn_traits)]
#[inline]
pub fn a() {
FnOnce::call_once(a, ());
FnOnce::call_once(b, ());
}
#[inline]
pub fn b() {
FnOnce::call_once(b, ());
FnOnce::call_once(a, ());
}
```
This should demonstrate the issue. For ease of discussion, I'm gonna call the two fn-def types `{a}` and `{b}`.
When collecting the cyclic local callees in `mir_callgraph_cyclic` for `a`, we first check the first call terminator in `a`. We end up calling process on `<{a} as FnOnce>::call_once`, which ends up visiting `a`'s instance again. This is cyclical. However, we don't end up marking `FnOnce::call_once` as a cyclical def id because it's a foreign item. That's fine.
When visiting the second call terminator in `a`, which is `<{b} as FnOnce>::call_once`, we end up recursing into `b`. We check the first terminator, which is `<{b} as FnOnce>::call_once`, but although that is its own mini cycle, it doesn't consider itself a cycle for the purpose of this query because it doesn't involve the *root*. However, when we visit the *second* terminator in `b`, which is `<{a} as FnOnce>::call_once`, we end up **erroneously** *not* considering that call to be cyclical since we've already inserted it into our set of seen instances, and as a consequence we don't recurse into it. This means that we never collect `b` as recursive.
Do this in the flipped case too, and we end up having two functions which mututally do not consider each other to be recursive participants. This leads to a query cycle.
---
I ended up also renaming some variables so I could more clearly understand their responsibilities in this code. Let me know if the renames are not welcome.
Fixes https://github.com/rust-lang/rust/issues/143700
r? `@cjgillot`
fix Zip unsoundness (again)
Some history: The Zip TrustedRandomAccess specialization has tried to emulate the side-effects of the naive implementation for a long time, including backwards iteration. #82292 tried to fix unsoundness (#82291) in that side-effect-preservation code, but this introduced some panic-safety unsoundness (#86443), but the fix#86452 didn't fix it for nested Zip iterators (#137255).
Rather than piling yet another fix ontop of this heap of fixes this PR reduces the number of cases in which side-effects will be preserved; the necessary API guarantee change was approved in #83791 but we haven't made use of that so far.
fixes#137255
Generalize `unsize` and `unsize_into` destinations
Just something that I noticed during other work. We do this for most such functions, so let's do it here, too.
r? ``@RalfJung``
Refactor `CrateLoader` into the `CStore`
Removes the `CrateLoader` and moves the code to `CStore`. Now, if you want to use the `CrateLoader`, you can just use `CStore`.
Should we rename `creader.rs` to `cstore.rs`?
r? ``@petrochenkov``
Fix encoding of link_section and no_mangle cross crate
Fixes https://github.com/rust-lang/rust/issues/144004
``@bjorn3`` suggested using the `codegen_fn_attrs` query but given that these attributes are not that common it's probably fine to just always encode them. I can also go for that solution if it is preferred but that would require more changes.
r? ``@jdonszelmann`` ``@fmease`` (whoever feels like it)
opt-dist: make llvm builds optional
adds command line option for disabling llvm builds. it's useful in case of user having their own optimized LLVM, so they won't waste time for (at least) 3 LLVM builds. in this case PGO optimized rustc will be already built in Stage 1, so rust-lang/rust#143898 should be addressed for this change
couldn't test locally on Linux laptop due to small SSD storage, will try now with windows-msvc host
r? ``@Kobzol``
try-job: dist-x86_64-linux
try-job: dist-x86_64-msvc
Show the offset, length and memory of uninit read errors
r? ``@RalfJung``
I want to improve memory dumps in general. Not sure yet how to do so best within rust diagnostics, but in a perfect world I could generate a dummy in-memory file (that contains the rendered memory dump) that we then can then provide regular rustc `Span`s to. So we'd basically report normal diagnostics for them with squiggly lines and everything.
Split-up stability_index query
This PR aims to move deprecation and stability processing away from the monolithic `stability_index` query, and directly implement `lookup_{deprecation,stability,body_stability,const_stability}` queries.
The basic idea is to:
- move per-attribute sanity checks into `check_attr.rs`;
- move attribute compatibility checks into the `MissingStabilityAnnotations` visitor;
- progressively dismantle the `Annotator` visitor and the `stability_index` query.
The first commit contains functional change, and now warns when `#[automatically_derived]` is applied on a non-trait impl block. The other commits should not change visible behaviour.
Perf in https://github.com/rust-lang/rust/pull/143845#issuecomment-3066308630 shows small but consistent improvement, except for unused-warnings case. That case being a stress test, I'm leaning towards accepting the regression.
This PR changes `check_attr`, so has a high conflict rate on that file. This should not cause issues for review.
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#143280 (Remove duplicate error about raw underscore lifetime)
- rust-lang/rust#143649 (Add test for `default_field_values` and `const_default`)
- rust-lang/rust#143699 (Make `AsyncDrop` check that it's being implemented on a local ADT)
- rust-lang/rust#143908 (`tests/ui`: A New Order [0/28] )
- rust-lang/rust#143909 (docs(alloc::fmt): Make type optional, instead of matching empty string)
- rust-lang/rust#143925 (Make slice comparisons const)
- rust-lang/rust#143997 (Use $crate in macros for rustc_public (aka stable_mir))
- rust-lang/rust#144013 (resolve: Make disambiguators for underscore bindings module-local)
- rust-lang/rust#144029 (Fix wrong messages from methods with the same name from different traits)
- rust-lang/rust#144063 (Add myself to the `infra-ci` reviewer group and adjust some infra auto-labels)
- rust-lang/rust#144069 (ci: use windows 22 for all free runners)
r? `@ghost`
`@rustbot` modify labels: rollup
Add myself to the `infra-ci` reviewer group and adjust some infra auto-labels
- Commit 1 is a drive-by adjustment. Auto-label `src/ci` and `.github/workflows` with https://github.com/rust-lang/rust/labels/A-CI, and include `.github/workflows` for https://github.com/rust-lang/rust/labels/T-infra trigger files.
- Commit 2 adds myself to the `infra-ci` reviewer adhoc group.
r? ``````@Kobzol``````
resolve: Make disambiguators for underscore bindings module-local
Disambiguators attached to underscore name bindings (like `const _: u8 = something;`) do not need to be globally unique, they just need to be unique inside the module in which they live, because the bindings in a module are basically kept as `Map<BindingKey, SomeData>`.
Also, the specific values of the disambiguators are not important, so a glob import of `const _` may have a different disambiguator than the original `const _` itself.
So in this PR the disambiguator is just set to the current number of bindings in the module.
This removes one more piece of global mutable state from resolver and unblocks https://github.com/rust-lang/rust/pull/143884.
Use $crate in macros for rustc_public (aka stable_mir)
This makes `#[macro_use] extern crate rustc_public` unnecessary (which brings all of `rustc_public`'s macros into scope for the entire crate); instead, now you can simply use `rustc_public::run!()`.
Make slice comparisons const
This needed a fix for `derive_const`, too, as it wasn't usable in libcore anymore as trait impls need const stability attributes. I think we can't use the same system as normal trait impls while `const_trait_impl` is still unstable.
r? ```@fee1-dead```
cc rust-lang/rust#143800
docs(alloc::fmt): Make type optional, instead of matching empty string
Think this is clearer.
Noticed as I was implementing [`tree-sitter-rust-format-args`](https://github.com/nik-rev/tree-sitter-rust-format-args), and attempting to match the empty string results in an error.
`tests/ui`: A New Order [0/28]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
These are the some last tests that didn’t make it into the main twenty-eightology of PRs. Part of rust-lang/rust#133895.
r? ```@jieyouxu```
Add test for `default_field_values` and `const_default`
Add a test showing `#![feature(default_field_values)]` using `#[const_trait] trait Default` (`#![feature(const_default)]` + `#![feature(const_trait_impl)]`).
CC https://github.com/rust-lang/rust/issues/132162
