run_make_support: skip rustfmt for lib.rs
To avoid them getting reordered once https://github.com/rust-lang/rust/pull/125443 goes through.
r? ``@nnethercote`` (since you were working on this)
match lowering: Split `finalize_or_candidate` into more coherent methods
I noticed that `finalize_or_candidate` was responsible for several different postprocessing tasks, making it difficult to understand.
This PR aims to clean up some of the confusion by:
- Extracting `remove_never_subcandidates` from `merge_trivial_subcandidates`
- Extracting `test_remaining_match_pairs_after_or` from `finalize_or_candidate`
- Taking what remains of `finalize_or_candidate`, and inlining it into its caller
---
Reviewing individual commits and ignoring whitespace is recommended.
Most of the large-looking changes are just moving existing code around, mostly unaltered.
r? ``@Nadrieril``
kmc-solid: `#![forbid(unsafe_op_in_unsafe_fn)]`
The path logic _should_ handle the forbiddance in the itron sources correctly, despite them being an "out-of-line" module.
unix: document unsafety for std `sig{action,altstack}`
I found many surprising elements here while trying to wrap a measly 5 functions with `unsafe`. I would rather not "just" mindlessly wrap this code with `unsafe { }`, so I decided to document it properly.
On Unix, this code covers the "create and setup signal handler" part of the stack overflow code, and serves as the primary safety boundary for the signal handler. It is rarely audited, very gnarly, and worth extra attention. It calls other unsafe functions defined in this module, but "can we correctly map the right memory, or find the right address ranges?" are separate questions, and get increasingly platform-specific. The question here is the more general "are we doing everything in the correct order, and setting up the handler in the correct way?"
As part of this audit, I noticed that we do some peculiar things that we should probably refrain from. However, I avoided making changes that I deemed might have a different final result in Rust programs. I did, however, reorder some events so that the signal handler is installed _after_ we install the alternate stack. We do not run much code between these events, but it is probably best if the timespan between the handler being available and the new stack being installed is 0 nanoseconds.
Add a hook for `should_codegen_locally`
This PR lifts the module-local function `should_codegen_locally` to `TyCtxt` as a hook.
In addition to monomorphization, this function is used for checking the dependency of `compiler_builtins` on other libraries. Moving this function to the hooks also makes overriding it possible for the tools that use the rustc interface.
use precompiled rustdoc with CI rustc
When CI rustc is enabled and rustdoc sources are unchanged, we can use the precompiled rustdoc from the CI rustc's sysroot. This speeds up bootstrapping quite a lot by avoiding unnecessary rustdoc compilation.
When CI rustc is enabled and rustdoc sources are unchanged, we can use
the precompiled rustdoc from the CI rustc's sysroot. This speeds up
bootstrapping quite a lot by avoiding unnecessary rustdoc compilation.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Rollup of 9 pull requests
Successful merges:
- #123196 (Add Process support for UEFI)
- #127556 (Replace a long inline "autoref" comment with method docs)
- #127693 (Migrate `crate-hash-rustc-version` to `rmake`)
- #127866 (Conditionally build `wasm-component-ld` )
- #127918 (Safely enforce thread name requirements)
- #127948 (fixes panic error `index out of bounds` in conflicting error)
- #127980 (Avoid ref when using format! in compiler)
- #127984 (Avoid ref when using format! in src)
- #127987 (More accurate suggestion for `-> Box<dyn Trait>` or `-> impl Trait`)
r? `@ghost`
`@rustbot` modify labels: rollup
Add a test for #107975
The int is zero. But also not zero. This is so much fun.
This is a part of #105107.
Initially I was going to just rebase #108445, but quite a few things changed since then:
* The [mcve](https://github.com/rust-lang/rust/issues/105787#issuecomment-1750112388) used for #105787 got fixed.[^upd2]
* You can't just `a ?= b` for #107975 anymore. Now you have to `a-b ?= 0`. This is what this PR does. As an additional flex, it show that three ways of converting a pointer to its address have this issue:
1. `as usize`
2. `.expose_provenance()`
3. `.addr()`
* #108425 simply got fixed. Yay.
As an aside, the naming for `addr_of!` is quite unfortunate in context of provenance APIs. Because `addr_of!` gives you a pointer, but what provenance APIs refer to as "address" is the `usize` value. Oh well.
UPD1: GitHub is incapable of parsing #107975 in the PR name, so let's add it here.
[^upd2]: UPD2: [The other mcve](https://github.com/rust-lang/rust/issues/105787#issue-1500501670) does not work anymore either, saying "this behavior recently changed as a result of a bug fix; see rust-lang/rust#56105 for details."
More accurate suggestion for `-> Box<dyn Trait>` or `-> impl Trait`
When encountering `-> Trait`, suggest `-> Box<dyn Trait>` (instead of `-> Box<Trait>`.
If there's a single returned type within the `fn`, suggest `-> impl Trait`.
Avoid ref when using format! in src
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing). Inlining format args prevents accidental `&` misuse.
See also https://github.com/rust-lang/rust-clippy/issues/10851
Avoid ref when using format! in compiler
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing). Inlining format args prevents accidental `&` misuse.
See also https://github.com/rust-lang/rust-clippy/issues/10851
Safely enforce thread name requirements
The requirements for the thread name to be both UTF-8 and null terminated are easily enforced by a wrapper type so lets do that. The fact this used to be just a bare `CString` has tripped me up before because it was entirely safe to use a non UTF-8 `CString`.
Conditionally build `wasm-component-ld`
This commit updates the support for the `wasm-component-ld` tool from #126967 to conditionally build rather than unconditionally building it when LLD is enabled. This support is disabled by default and can be enabled by one of two means:
* the `extended` field in `config.toml` which dist builders use to build a complete set of tools for each host platform.
* a `"wasm-component-ld"` entry in the `tools` section of `config.toml`.
Neither of these are enabled by default meaning that most local builds will likely not have this new tool built. Dist builders should still, however, build the tool.
Replace a long inline "autoref" comment with method docs
This comment has two problems:
- It is very long, making the flow of the enclosing method hard to follow.
- It starts by talking about an `autoref` flag that hasn't existed since #59114.
- This makes it hard to trust that the information in the comment is accurate or relevant, even though much of it still seems to be true.
This PR therefore replaces the long inline comment with a revised doc comment on `bind_matched_candidate_for_guard`, and some shorter inline comments.
For readers who want more historical context, we also link to the PR that added the old comment, and the PR that removed the `autoref` flag.
Add Process support for UEFI
UEFI does not have an actual process. However, it does provide methods to launch and execute another UEFI image. Having process support is important since it is possible to run rust test suit using `Command::output` and is the first step towards being able to run it for UEFI.
Here is an overview of how the support is implemented.
- We create a copy of the SystemTable. This is required since at least OVMF seems to crash if the original system table is modified.
- Stdout and Stderr pipe works by registering a new `simple_text_output` Protocol and pointing the child system table to use those.
- `Stdio::Inherit` just points the console to the current running image console which seems to work with even 3 levels of process.
- `spawn` is left unimplemented since it does not make sense for UEFI architecture. Additionally, since https://github.com/rust-lang/rust/pull/105458 was merged, the `spawn` and `output` implementations are completely independent.
Update jsondocck directives to follow ui_test-style
Context: Comment chain in #125813.
Follow-up to #126788.
Use the same temporary approach of "double parsing" until we figure out how we want to support compiletest/ui_test directive "add-ons" for child test runners like HtmlDocCk and JsonDocCk.
I didn't touch much of jsondocck because I want to refactor it some other time (for robustness, maintainability and better diagnostics; basically by following a similar design of my WIP HtmlDocCk-next, cc #125780).
r? `@GuillaumeGomez`
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing). Inlining format args prevents accidental `&` misuse.
When encountering `-> Trait`, suggest `-> Box<dyn Trait>` (instead of `-> Box<Trait>`.
If there's a single returned type within the `fn`, suggest `-> impl Trait`.
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing). Inlining format args prevents accidental `&` misuse.
Rollup of 6 pull requests
Successful merges:
- #127295 (CFI: Support provided methods on traits)
- #127814 (`C-cmse-nonsecure-call`: improved error messages)
- #127949 (fix: explain E0120 better cover cases when its raised)
- #127966 (Use structured suggestions for unconstrained generic parameters on impl blocks)
- #127976 (Lazy type aliases: Diagostics: Detect bivariant ty params that are only used recursively)
- #127978 (Avoid ref when using format! for perf)
r? `@ghost`
`@rustbot` modify labels: rollup
Avoid ref when using format! for perf
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing). Inlining format args prevents accidental `&` misuse.
Lazy type aliases: Diagostics: Detect bivariant ty params that are only used recursively
Follow-up to errs's #127871. Extends the logic to cover LTAs, too, not just ADTs.
This change only takes effect with the next-gen solver enabled as cycle errors like
the one we have here are fatal in the old solver. That's my explanation anyways.
r? compiler-errors
Use structured suggestions for unconstrained generic parameters on impl blocks
I did not deduplicate with `UnusedGenericParameter`, because in contrast to type declarations, just using a generic parameter in an impl isn't enough, it must be used with the right variance and not just as part of a projection.
`C-cmse-nonsecure-call`: improved error messages
tracking issue: #81391
issue for the error messages (partially implemented by this PR): #81347
related, in that it also deals with CMSE: https://github.com/rust-lang/rust/pull/127766
When using the `C-cmse-nonsecure-call` ABI, both the arguments and return value must be passed via registers. Previously, when violating this constraint, an ugly LLVM error would be shown. Now, the rust compiler itself will print a pretty message and link to more information.
CFI: Support provided methods on traits
Provided methods currently don't get type erasure performed on them because they are not in an `impl` block. If we are instantiating a method that is an associated item, but *not* in an impl block, treat it as a provided method instead.
Disable run-make/split-debuginfo test for RISC-V 64
Together with `@Hoverbear,` we've been improving the state of the riscv64gc-unknown-linux-gnu target.
This is in relation to https://github.com/rust-lang/rust/pull/125220 where `tests/ui/debuginfo/debuginfo-emit-llvm-ir-and-split-debuginfo.rs` was disabled for RISC-V 64 in that another test, `tests/run-make/split-debuginfo` also needs to be disabled due to https://github.com/llvm/llvm-project/issues/56642 and the changes made in https://github.com/rust-lang/rust/pull/120518.
This test appears to be a host test, not a target test, so it isn't seen failing in https://github.com/rust-lang/rust/pull/126641, however, we are in the process of testing host tools for riscv64-gc-unknown-linux-gnu so this test has now been noticed to be a problem.
Cleanup dll/exe filename calculations in `run_make_support`
Use `std::env::consts` constants since now we have access to them (unlike in Makefiles!) ^^
cc `@bzEq` (this is one of the places in our test suites that tries to compute e.g. dylib extension; using `std::env::consts::DLL_EXTENSION` should correctly return `a` for AIX)
r? `@fmease` (thank you for the suggestion in https://github.com/rust-lang/rust/pull/127760#discussion_r1678079698, this also improves correctness for the support library!)
try-job: aarch64-apple
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc
try-job: x86_64-gnu-llvm-18
interpret: add sanity check in dyn upcast to double-check what codegen does
For dyn receiver calls, we already have two codepaths: look up the function to call by indexing into the vtable, or alternatively resolve the DefId given the dynamic type of the receiver. With debug assertions enabled, the interpreter does both and compares the results. (Without debug assertions we always use the vtable as it is simpler.)
This PR does the same for dyn trait upcasts. However, for casts *not* using the vtable is the easier thing to do, so now the vtable path is the debug-assertion-only path. In particular, there are cases where the vtable does not contain a pointer for upcasts but instead reuses the old pointer: when the supertrait vtable is a prefix of the larger vtable. We don't want to expose this optimization and detect UB if people do a transmute assuming this optimization, so we cannot in general use the vtable indexing path.
r? ``@oli-obk``
Add `isqrt` to `NonZero<uN>`
Implements [#70887 (comment)](https://github.com/rust-lang/rust/issues/116226#issuecomment-2144225174), with the following signature:
```rust
impl NonZero<uN> {
const fn isqrt(self) -> Self;
}
```
Unintended benefits include one fewer panicking branch in `ilog2` for LLVM to optimize away, and one fewer `assume_unchecked` as `NonZero` already does that.
The fast path for `self == 1` is dropped, but the current implementation is very slow anyways compared to hardware. Performance improvements can always come later.
(I didn't add the function to `NonZero<iN>`, since _every_ existing `NonZero` method is non-panicking, and it might be nice to leave it that way.)
