| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- #122422 (compiletest: Allow `only-unix` in test headers)
- #122424 (fix: typos)
- #122425 (Increase timeout for new bors bot)
- #122426 (Fix StableMIR `WrappingRange::is_full` computation)
- #122429 (Add Exploit Mitigations PG to triagebot.toml)
- #122430 (Generate link to `Local` in `hir::Let` documentation)
- #122434 (pattern analysis: rename a few types)
- #122437 (pattern analysis: remove `MaybeInfiniteInt::JustAfterMax`)
- #122438 (Safe Transmute: Require that source referent is smaller than destination)
- #122442 (extend docs of -Zprint-mono-items)
- #122449 (Delay a bug for stranded opaques)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Revert "Auto merge of #122140 - oli-obk:track_errors13, r=davidtwco"
This reverts commit 65cd843ae06ad00123c131a431ed5304e4cd577a, reversing changes made to d255c6a57c393db6221b1ff700daea478436f1cd.
reverts https://github.com/rust-lang/rust/pull/122140
It was a large regression in wall time due to trashing CPU caches
|
|
pnkfelix:downgrade-const-eval-dnagling-ptr-in-final-to-future-incompat-lint, r=wesleywiser
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.
|
|
Delay a bug for stranded opaques
r? oli-obk
Fixes #122445
|
|
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 :smile:
r? ``@compiler-errors``
|
|
Generate link to `Local` in `hir::Let` documentation
This PR adds a missing link generation to `Local` type.
|
|
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.
|
|
fix: typos
|
|
|
|
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`
|
|
|
|
|
|
|
|
lint.
|
|
to address issue 121610.
|
|
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`
|
|
It was inherited from before half-open ranges, but it doesn't pull its
weight anymore. We lose a tiny bit of diagnostic precision.
|
|
|
|
|
|
The old name came from a time where I wanted to reuse it for
differentiating wildcards from bindings. I don't plan to do this
anymore.
|
|
|
|
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
|
|
Signed-off-by: guoguangwu <guoguangwug@gmail.com>
|
|
Fix ICE in diagnostics for parenthesized type arguments
The second time is the charm :crossed_fingers: :grin:
Fixes #122345
r? fmease
|
|
Don't Create `ParamCandidate` When Obligation Contains Errors
Fixes #121941
I'm not sure if I understand this correctly but this bug was caused by an error type incorrectly matching against `ParamCandidate`. This was introduced by the changes made in #72621 (figured using cargo-bisect-rustc).
This PR fixes it by skipping `ParamCandidate` generation when an error type is involved. Also, this is similar to #73005 but addresses `ParamCandidate` instead of `ImplCandidate`.
|
|
coverage: Remove or migrate all unstable values of `-Cinstrument-coverage`
(This PR was substantially overhauled from its original version, which migrated all of the existing unstable values intact.)
This PR takes the three nightly-only values that are currently accepted by `-Cinstrument-coverage`, completely removes two of them (`except-unused-functions` and `except-unused-generics`), and migrates the third (`branch`) over to a newly-introduced unstable flag `-Zcoverage-options`.
I have a few motivations for wanting to do this:
- It's unclear whether anyone actually uses the `except-unused-*` values, so this serves as an opportunity to either remove them, or prompt existing users to object to their removal.
- After #117199, the stable values of `-Cinstrument-coverage` treat it as a boolean-valued flag, so having nightly-only extra values feels out-of-place.
- Nightly-only values also require extra ad-hoc code to make sure they aren't accidentally exposed to stable users.
- The new system allows multiple different settings to be toggled independently, which isn't possible in the current single-value system.
- The new system makes it easier to introduce new behaviour behind an unstable toggle, and then gather nightly-user feedback before possibly making it the default behaviour for all users.
- The new system also gives us a convenient place to put relatively-narrow options that won't ever be the default, but that nightly users might still want access to.
- It's likely that we will eventually want to give stable users more fine-grained control over coverage instrumentation. The new flag serves as a prototype of what that stable UI might eventually look like.
The `branch` option is a placeholder that currently does nothing. It will be used by #122322 to opt into branch coverage instrumentation.
---
I see `-Zcoverage-options` as something that will exist more-or-less indefinitely, though individual sub-options might come and go as appropriate. I think there will always be some demand for nightly-only toggles, so I don't see `-Zcoverage-options` itself ever being stable, though we might eventually stabilize something similar to it.
|
|
Add `intrinsic_name` to get plain intrinsic name
Add an `intrinsic_name` API to retrieve the plain intrinsic name. The plain name does not include type arguments (as `trimmed_name` does), which is more convenient to match with intrinsic symbols.
|
|
match lowering: don't collect test alternatives ahead of time
I'm very happy with this one. Before this, when sorting candidates into the possible test branches, we manually computed `usize` indices to determine in which branch each candidate goes. To make this work we had a first pass that collected the possible alternatives we'd have to deal with, and a second pass that actually sorts the candidates.
In this PR, I replace `usize` indices with a dedicated enum. This makes `sort_candidates` easier to follow, and we don't need the first pass anymore.
r? ``@matthewjasper``
|
|
pattern analysis: Store field indices in `DeconstructedPat` to avoid virtual wildcards
For a pattern like `Struct { field3: true, .. }`, in pattern analysis we represent it as `Struct { field1: _, field2: _, field3: true, field4: _ }`. This PR makes it so we store `Struct { field3: true, .. }` instead. This means we never have to create fake `_` patterns during lowering.
r? ``@compiler-errors``
|
|
Avoid lowering code under dead SwitchInt targets
The objective of this PR is to detect and eliminate code which is guarded by an `if false`, even if that `false` is a constant which is not known until monomorphization, or is `intrinsics::debug_assertions()`.
The effect of this is that we generate no LLVM IR the standard library's unsafe preconditions, when they are compiled in a build where they should be immediately optimized out. This mono-time optimization ensures that builds which disable debug assertions do not grow a linkage requirement against `core`, which compiler-builtins currently needs: https://github.com/rust-lang/rust/issues/121552
This revives the codegen side of https://github.com/rust-lang/rust/pull/91222 as planned in https://github.com/rust-lang/rust/issues/120848.
|
|
Verify that query keys result in unique dep nodes
This implements checking that query keys result into unique dep nodes as mentioned in https://github.com/rust-lang/rust/pull/112469.
We could do a perf check to see how expensive this is.
r? `@michaelwoerister`
|
|
This new nightly-only flag can be used to toggle fine-grained flags that
control the details of coverage instrumentation.
Currently the only supported flag value is `branch` (or `no-branch`), which is
a placeholder for upcoming support for branch coverage. Other flag values can
be added in the future, to prototype proposed new behaviour, or to enable
special non-default behaviour.
|
|
|
|
Only generate a ptrtoint in AtomicPtr codegen when absolutely necessary
This special case was added in this PR: https://github.com/rust-lang/rust/pull/77611 in response to this error message:
```
Intrinsic has incorrect argument type!
void ({}*)* `@llvm.ppc.cfence.p0sl_s`
in function rust_oom
LLVM ERROR: Broken function found, compilation aborted!
[RUSTC-TIMING] std test:false 20.161
error: could not compile `std`
```
But when I tried searching for more information about that intrinsic I found this: https://github.com/llvm/llvm-project/issues/55983 which is a report of someone hitting this same error and a fix was landed in LLVM, 2 years after the above Rust PR.
|
|
|
|
|
|
|
|
Fixes #121941
|
|
Rollup of 12 pull requests
Successful merges:
- #121754 ([bootstrap] Move the `split-debuginfo` setting to the per-target section)
- #121953 (Add tests for the generated assembly of mask related simd instructions.)
- #122081 (validate `builder::PATH_REMAP`)
- #122245 (Detect truncated DepGraph files)
- #122354 (bootstrap: Don't eagerly format verbose messages)
- #122355 (rustdoc: fix up old test)
- #122363 (tests: Add ui/attributes/unix_sigpipe/unix_sigpipe-str-list.rs)
- #122366 (Fix stack overflow with recursive associated types)
- #122377 (Fix discriminant_kind copy paste from the pointee trait case)
- #122378 (Properly rebuild rustbooks)
- #122380 (Fix typo in lib.rs of proc_macro)
- #122381 (llvm-wrapper: adapt for LLVM API changes)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
llvm-wrapper: adapt for LLVM API changes
Adapts rust for https://github.com/llvm/llvm-project/commit/9997e0397156ff7e01aecbd17bdeb7bfe5fb15b0.
`@rustbot` label: +llvm-main
r? `@durin42`
|
