With the previous improvements, it is now possible to run float parsing
tests as part of CI. Enable it here.
This only runs a subset of tests, which takes about one minute.
With updates to `test-float-parse`, it is now possible to run as another
Rust tool. Enable check, clippy, and test.
Test runs the unit tests, as well as shorter parsing tests (takes
approximately 1 minute).
The existing implementation uses Python to launch a set of Rust-written
binaries. Unfortunately, this is currently broken; it seems that some
updates meant it no longer compiles.
There is also a problem that support for more float types (`f16`,
`f128`) would be difficult to add since this is very specialized to
`f32` and `f64`.
Because of these sortcomings, migrate to a version written in Rust. This
version should be significantly faster; test generators can execute in
parallel, and test cases are chunked and parallelized. This should also
resolve the preexisting "... the worker processes are leaked and stick
around forever" comment.
This change also introduces genericism over float types and properties,
meaning it will be much easier to extend support to newly added types.
`num::BigRational` is used in place of Python's fractions for
infinite-precision calculations.
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
