Various style improvements to `rustc_lint::levels`
While reading this file, I noticed a few opportunities to make things a little nicer:
- Replace some nested if-let with let-chains
- Tweak a match pattern to allow shorthand struct syntax
- Fuse an `is_empty` check with getting the last element
- Merge some common code that emits `MalformedAttribute` and continues
- Format `"{tool}::{name}"` in a way that's consistent with other match arms
- Replace if-let-else-panic with let-else
- Use early-exit to flatten a method body
Some of these changes cause indentation churn, so ignoring whitespace is recommended.
Add methods to create StableMIR constant
I've been experimenting with transforming the StableMIR to instrument the code with potential UB checks.
The modified body will only be used by our analysis tool, however, constants in StableMIR must be backed by rustc constants. Thus, I'm adding a few functions to build constants, such as building string and other primitives.
One question I have is whether we should create a global allocation instead for strings.
r? ``````@oli-obk``````
interpret: ensure that Place is never used for a different frame
We store the address where the stack frame stores its `locals`. The idea is that even if we pop and push, or switch to a different thread with a larger number of frames, then the `locals` address will most likely change so we'll notice that problem. This is made possible by some recent changes by `@WaffleLapkin,` where we no longer use `Place` across things that change the number of stack frames.
I made these debug assertions for now, just to make sure this can't cost us any perf.
The first commit is unrelated but it's a one-line comment change so it didn't warrant a separate PR...
r? `@oli-obk`
Downgrade const eval dangling ptr in final to future incompat lint
Short term band-aid for issue #121610, downgrading the prior hard error to a future-incompat lint (tracked in issue #122153).
Note we should not mark #121610 as resolved until after this (or something analogous) is beta backported.
extend docs of -Zprint-mono-items
Currently the values one can set this to are not documented anywhere.
I think ideally this flag wouldn't overwrite the collector's behavior, a "print" flag should just print what happens but not change what happens. But our codegen-units tests rely on being able to collect all items without the other side-effects of `-C link-dead-code` and I can't tell whether that reliance is incidental or crucial, so I'm not touching this and just documenting the (messy) status quo.
Safe Transmute: Require that source referent is smaller than destination
`BikeshedIntrinsicFrom` currently models transmute-via-union; i.e., it attempts to provide a `where` bound for this function:
```rust
pub unsafe fn transmute_via_union<Src, Dst>(src: Src) -> Dst {
use core::mem::*;
#[repr(C)]
union Transmute<T, U> {
src: ManuallyDrop<T>,
dst: ManuallyDrop<U>,
}
let transmute = Transmute { src: ManuallyDrop::new(src) };
// SAFETY: The caller must guarantee that the transmutation is safe.
let dst = transmute.dst;
ManuallyDrop::into_inner(dst)
}
```
A quirk of this model is that it admits padding extensions in value-to-value transmutation: The destination type can be bigger than the source type, so long as the excess consists of uninitialized bytes. However, this isn't permissible for reference-to-reference transmutations (introduced in #110662) — extra referent bytes cannot come from thin air.
This PR patches our analysis for reference-to-reference transmutations to require that the destination referent is no larger than the source referent.
r? `@compiler-errors`
pattern analysis: remove `MaybeInfiniteInt::JustAfterMax`
It was inherited from before half-open ranges, but it doesn't pull its weight anymore. We lose a tiny bit of diagnostic precision as can be seen in the test. I'm generally in favor of half-open ranges over explicit `x..=MAX` ranges anyway.
pattern analysis: rename a few types
A few long overdue renames. `ValidityConstraint` was supposed to serve double purpose but I don't need that anymore. I don't know what I was thinking with `TypeCx` I think I was trying to be clever. That's fixed now 😄
r? ``@compiler-errors``
Fix StableMIR `WrappingRange::is_full` computation
`WrappingRange::is_full` computation assumed that to be full the range couldn't wrap, which is not necessarily true.
For example, a range of 1..=0 is a valid representation of a full wrapping range.
This adds the unstable `-Z external-sanitizer-runtime` flag that will
prevent rustc from emitting linker paths for the in-tree LLVM sanitizer
runtime library.
The source referent absolutely must be smaller than the destination
referent of a ref-to-ref transmute; the excess bytes referenced
cannot arise from thin air, even if those bytes are uninitialized.
Represent `Result<usize, Box<T>>` as ScalarPair(i64, ptr)
This allows types like `Result<usize, std::io::Error>` (and integers of differing sign, e.g. `Result<u64, i64>`) to be passed in a pair of registers instead of through memory, like `Result<u64, u64>` or `Result<Box<T>, Box<U>>` are today.
Fixes#97540.
r? `@ghost`
delay expand macro bang when there has indeterminate path
Related #98291
I will attempt to clarify the root problem through several examples:
Firstly,
```rs
// rustc code.rs --edition=2018
macro_rules! wrap {
() => {
macro_rules! _a {
() => {
"Hello world"
};
}
};
}
wrap!();
use _a as a;
fn main() {
format_args!(_a!());
}
```
The above case will compile successfully because `_a` is defined after the `wrap` expaned, ensuring `_a` can be resolved without any issues.
And,
```rs
// rustc code.rs --edition=2018
macro_rules! wrap {
() => {
macro_rules! _a {
() => {
"Hello world"
};
}
};
}
wrap!();
use _a as a;
fn main() {
format_args!("{}", a!());
}
```
The above example will also compile successfully because the `parse_args` in `expand_format_args_impl` will return a value `MacroInput { fmtstr: Expr::Lit::Str, args: [Expr::MacroCall]}`. Since the graph for `args` will be build lately, `a` will eventually be resolved.
However, in the case of:
```rs
// rustc code.rs --edition=2018
macro_rules! wrap {
() => {
macro_rules! _a {
() => {
"Hello world"
};
}
};
}
wrap!();
use _a as a;
fn main() {
format_args!(a!());
}
```
The result of `parse_args` is `MacroInput {fmtstr: Expr::Lit::Macro, args: [] }`, we attempt to expand `fmtstr` **eagerly** within `expr_to_spanned_string`. Although we have recorded `(root, _a)` into resolutions, `use _a as a` is an indeterminate import, which will not try to resolve under the conditions of `expander.monotonic = false`.
Therefore, I've altered the strategy for resolving indeterminate imports, ensuring it will also resolve during eager expansion. This could be a significant change to the resolution infra. However, I think it's acceptable if the goal of avoiding resolution under eager expansion is to save time.
r? `@petrochenkov`
This will allow MIR building to check whether a function is eligible for
coverage instrumentation, and avoid collecting branch coverage info if it is
not.
miri: add some chance to reuse addresses of previously freed allocations
The hope is that this can help us find ABA issues.
Unfortunately this needs rustc changes so I can't easily run the regular benchmark suite. I used `src/tools/miri/tests/pass/float_nan.rs` as a substitute:
```
Before:
Benchmark 1: ./x.py run miri --stage 0 --args src/tools/miri/tests/pass/float_nan.rs --args --edition=2021
Time (mean ± σ): 9.570 s ± 0.013 s [User: 9.279 s, System: 0.290 s]
Range (min … max): 9.561 s … 9.579 s 2 runs
After:
Benchmark 1: ./x.py run miri --stage 0 --args src/tools/miri/tests/pass/float_nan.rs --args --edition=2021
Time (mean ± σ): 9.698 s ± 0.046 s [User: 9.413 s, System: 0.279 s]
Range (min … max): 9.666 s … 9.731 s 2 runs
```
That's a ~1.3% slowdown, which seems fine to me. I have seen a lot of noise in this style of benchmarking so I don't quite trust this anyway; we can make further experiments in the Miri repo after this migrated there.
r? `@oli-obk`
`WrappingRange::is_full` computation assumed that to be full the range
couldn't wrap, which is not necessarily true.
For example, a range of 1..=0 is a valid representation of a full
wrapping range.
Rollup of 10 pull requests
Successful merges:
- #121820 (pattern analysis: Store field indices in `DeconstructedPat` to avoid virtual wildcards)
- #121908 (match lowering: don't collect test alternatives ahead of time)
- #122203 (Add `intrinsic_name` to get plain intrinsic name)
- #122226 (coverage: Remove or migrate all unstable values of `-Cinstrument-coverage`)
- #122255 (Use `min_exhaustive_patterns` in core & std)
- #122360 ( Don't Create `ParamCandidate` When Obligation Contains Errors )
- #122383 (Enable PR tracking review assignment for rust-lang/rust)
- #122386 (Move `Once` implementations to `sys`)
- #122400 (Fix ICE in diagnostics for parenthesized type arguments)
- #122410 (rustdoc: do not preload fonts when browsing locally)
r? `@ghost`
`@rustbot` modify labels: rollup
