For runtime dependencies we have a much stricter license check.
Combining the license check code with that for regular tools makes it
harder to follow.
Extend `impl`'s `def_span` to include its where clauses
Typically, we highlight the def-span of an impl in a diagnostic due to either:
1. coherence error
2. trait evaluation cycle
3. invalid implementation of built-in trait
I find that an impl's where clauses are very often required to understanding why these errors come about, which is unfortunate since where clauses may be located on different lines and don't show up in the error. This PR expands the def-span of impls to include these where clauses.
r? cjgillot since you've touched this code a while back to make some spans shorter, but you can also reassign to wg-diagnostics or compiler if you're busy or have no strong opinions.
Add RUSTFLAGS_BOOTSTRAP to RUSTFLAGS for bootstrap compilation
Adds `RUSTFLAGS_BOOTSTRAP` to `RUSTFLAGS` for bootstrap compilation when `RUSTFLAGS_BOOTSTRAP` exists in the environment. With this PR, `RUSTFLAGS_BOOTSTRAP` will affect every build(as we already do for rustc and std) compiled with stage0 compiler.
Resolves#94234
Rollup of 6 pull requests
Successful merges:
- #115882 (improve the suggestion of `generic_bound_failure`)
- #116537 (Fix suggestion span involving wrongly placed generic arg on variant)
- #116543 (In smir `find_crates` returns `Vec<Crate>` instead of `Option<Crate>`)
- #116549 (Simplify some mir passes by using let chains)
- #116556 (Sync rustc_codegen_cranelift)
- #116561 (Add a test for fixed ICE)
r? `@ghost`
`@rustbot` modify labels: rollup
Sync rustc_codegen_cranelift
The highlights this time are improved simd and inline asm support, `is_x86_feature_detected!()` returning the actual cpu features when inline asm support is enabled and a couple of bug fixes.
r? ```@ghost```
```@rustbot``` label +A-codegen +A-cranelift +T-compiler +subtree-sync
[rustdoc] Show enum discrimant if it is a C-like variant
Fixes https://github.com/rust-lang/rust/issues/101337.
We currently display values for associated constant items in traits:
And we also display constant values like [here](file:///home/imperio/rust/rust/build/x86_64-unknown-linux-gnu/doc/std/f32/consts/constant.E.html).
I think that for coherency, we should display values of C-like enum variants.
With this change, it looks like this:
As for the display of the constant value itself, I used what we already have to keep coherency.
We display the C-like variants value in the following scenario:
1. It is a C-like variant with a value set => all the time
2. It is a C-like variant without a value set: All other variants are C-like variants and at least one them has its value set.
Here is the result in code:
```rust
// Ax and Bx value will be displayed.
enum A {
Ax = 12,
Bx,
}
// Ax and Bx value will not be displayed
enum B {
Ax,
Bx,
}
// Bx value will not be displayed
enum C {
Ax(u32),
Bx,
}
// Bx value will not be displayed, Cx value will be displayed.
#[repr(u32)]
enum D {
Ax(u32),
Bx,
Cx = 12,
}
```
r? `@notriddle`
Also be more pedantic about spelling:
- LE? Is it "less than or equal to"? Say "little endian".
- We're Rust, not C, preserve the initial capital in "N64".
- "MUSL" doesn't stand for anything; Rich Felker spells it "musl".
In the process, be more pedantic about spelling:
- LE? Do you mean "limited edition"? It's "little endian".
- The name of the ABI is "N64" as in "Nintendo 64".
Note that RUSTFLAGS_BOOTSTRAP should always be added to the end of
RUSTFLAGS to be actually effective (e.g., if we have `-Dwarnings` in
RUSTFLAGS, passing `-Awarnings` from RUSTFLAGS_BOOTSTRAP should override it).
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Bump host compiler on x64 dist Linux to LLVM 17.0.2
17.0.0-rc3 had a bunch of miscompilations, and it's probably better in general not to use a RC version of LLVM long term on CI.
Reserved loses permissions too quickly.
Adding more fine-grained behavior of Reserved lets it lose
write permissions only temporarily.
Protected tags receive a read access on initialized locations.
Support getentropy on macOS as a foreign item
Prior this was always assumed to be accessed via `dlsym` shim, but in `std` I'm attempting to start [unconditionally linking](https://github.com/rust-lang/rust/pull/116319) to `getentropy` on macOS now that Rust's platform version support allows it.
This just moves the main logic of the previous `dlsym` handler into an eval context extension so it can be used via both call paths. The `dlsym` handler is still needed as `getrandom` uses it.
