carryless_mul: mention the base
Arithmetic operations do not typically care about the base that is used to represent numbers, but this one does. Mentioning that makes it easier to understand the operation, I think.
Cc @folkertdev
Miri: recursive validity: also recurse into Boxes
Now that https://github.com/rust-lang/rust/issues/97270 is fixed, the recursive validity mode for Miri can recuse into Boxes without exploding everywhere.
make `rustc_allow_const_fn_unstable` an actual `rustc_attrs` attribute
It is already named like one, but used to have its own feature gate, which this PR now removes in favor of just using `#![feature(rustc_attrs)]`.
Most of the diff is just the line number changes in `malformed-attrs.stderr`.
Rework explanation of CLI lint level flags
I think the previous wording as either wrong or confusing. I would consider the CLI flags at a *lower* ranking, since source attributes are able to override the CLI flag.
Add documentation note about signed overflow direction
In https://github.com/rust-lang/rust/issues/151989#issuecomment-3845282666 I noticed that signed overflow direction can be determined by returned wrapped value. It is not very obvious (especially, assuming additional `carry: bool` summand), but it is important if we want to add new leading (signed) limb to big integer in this case.
Examples for small summands `x, y: i8` with result extension:
| x | y | overflow | result as (u8, i8) |
| ---- | ---- | -------- | ------------------ |
| -1 | -128 | true | (127, -1) |
| 0 | -1 | false | (255, -1) |
| 2 | 2 | false | (4, 0) |
| 127 | 1 | true | (128, 0) |
Here is general proof.
1. Set $s=2^{N-1}$ and let's say `iN::carrying_add(x, y, c)` returns `(result, true)` then
$$
\mathrm{result}=\begin{cases}
x + y + c + 2s,& x + y + c \le -s-1,\\
x+y+c-2s,& x+y+c\ge s.
\end{cases}
$$
First case is overflowing below `iN::MIN` and we have
$$
\mathrm{result}\ge -s-s+0+2s =0;\qquad
\mathrm{result}=x + y + c + 2s\le -s-1+2s = s - 1,
$$
so we obtain $[0; s-1]$ which is exactly range of non-negative `iN`.
Second case is overflowing above `iN::MAX` and
$$
\mathrm{result}=x+y+c-2s\ge s-2s =-s;\qquad
\mathrm{result}\le s-1 + s-1+1-2s = -1,
$$
that is, $[-s,-1]$ which is exactly range of negative `iN`.
2. Now suppose that `iN::borrowing_sub(x,y,b)` returns `(result, true)` then
$$
\mathrm{result}=\begin{cases}
x - y - b + 2s,& x - y - b \le -s-1,\\
x - y - b - 2s,& x - y - b\ge s.
\end{cases}
$$
First case is overflowing below `iN::MIN` and we have
$$
\mathrm{result}\ge -s-(s-1)-1+2s =0;\qquad
\mathrm{result}=x - y - b + 2s\le -s-1+2s = s - 1.
$$
Second case is overflowing above `iN::MAX` and
$$
\mathrm{result}=x-y-b-2s\ge s-2s =-s;\qquad
\mathrm{result}\le s-1 - (-s) - 0 - 2s = -1.
$$
Fix invalid `mut T` suggestion for `&mut T` in missing lifetime error
close: rust-lang/rust#150077
When suggesting to return an owned value instead of a borrowed one, the diagnostic was only removing `&` instead of `&mut `, resulting in invalid syntax like `mut T`. This PR fixes the span calculation to properly cover the entire `&mut ` prefix.
remove the explicit error for old `rental` versions
This was converted to a hard error 20 months ago (in rust-lang/rust#125596). This seems like enough time for anyone still using it to notice, so remove the note entirely now.
In comparison, the explicit note for the more impactful `time` breakage was already removed after 6 months (rust-lang/rust#129343).
Closesrust-lang/rust#73933.
Closesrust-lang/rust#83125.
r? @petrochenkov
Rename dep node "fingerprints" to distinguish key and value hashes
In the query system's dependency graph, each node is associated with two *fingerprints*: one that is typically a hash of the query key, and one that is typically a hash of the query's return value when called with that key.
Unfortunately, many identifiers and comments fail to clearly distinguish between these two kinds of fingerprint, which have very different roles in dependency tracking. This is a frequent source of confusion.
This PR therefore tries to establish a clear distinction between:
- **Key fingerprints** that help to uniquely identify a node (along with its `DepKind`), and are typically a hash of the query key
- **Value fingerprints** that help to determine whether a node can be marked green (despite having red dependencies), and are typically a hash of the query value
There should be no change to compiler behaviour.
r? nnethercote (or compiler)
compiler: Don't mark `SingleUseConsts` MIR pass as "required for soundness"
I don't think this MIR pass is required for soundness. The reasons are:
* Something like it was not enabled by default before PR rust-lang/rust#107404 which was the precursor to `SingleUseConsts` (see rust-lang/rust#125910 for the switch).
* By following the advice from https://github.com/rust-lang/rust/pull/128657#discussion_r1705114015 we can conclude it is not required for soundness since it has only ever run on MIR opt level > 0.
* Its [`MirPass::can_be_overridden()`](0ee7d96253/compiler/rustc_mir_transform/src/pass_manager.rs (L98-L102)) is unchanged and thus returns `true`, indicating that it is not a required MIR pass.
* PR CI pass in rust-lang/rust#151426 which stops enabling it by default in non-optimized builds.
As shown in the updated test `tests/mir-opt/optimize_none.rs`, `#[optimize(none)]` functions become even less optimized, as expected and desired.
Unblocks https://github.com/rust-lang/rust/pull/151426.
tail calls: fix copying non-scalar arguments to callee
Alternative to https://github.com/rust-lang/rust/pull/144933: when invoking a tail call with a non-scalar argument, we need to delay freeing the caller's local variables until after the callee is initialized, so that we can copy things from the caller to the callee.
Fixes https://github.com/rust-lang/rust/issues/144820... but as the FIXMEs in the code show, it's not clear to me whether these are the right semantics.
r? @WaffleLapkin
Unify wording of resolve error
Remove "failed to resolve" from the main error message and use the same format we use in other resolution errors "cannot find `name`":
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
The intent behind this is to end up with all resolve errors eventually be on the form of
```
error[ECODE]: cannot find `{NAME}` in {SCOPE}
--> $DIR/file.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ {SPECIFIC LABEL}
```
A category of errors that is interest are those that involve keywords. For example:
```
error[E0433]: cannot find `Self` in this scope
--> $DIR/issue-97194.rs:2:35
|
LL | fn bget(&self, index: [usize; Self::DIM]) -> bool {
| ^^^^ `Self` is only available in impls, traits, and type definitions
```
and
```
error[E0433]: cannot find `super` in this scope
--> $DIR/keyword-super.rs:2:9
|
LL | let super: isize;
| ^^^^^ there are too many leading `super` keywords
```
For these the label provides the actual help, while the message is less informative beyond telling you "couldn't find `name`".
This is an off-shoot of https://github.com/rust-lang/rust/pull/126810 and https://github.com/rust-lang/rust/pull/128086, a subset of the intended changes there with review comments applied.
r? @petrochenkov
Support JSON target specs in bootstrap
JSON target specs were destabilized in https://github.com/rust-lang/rust/pull/150151 and https://github.com/rust-lang/rust/pull/151534. However, this broke trying to build rustc itself with a JSON target spec. This is because in a few places bootstrap is manually calling `rustc` without the ability for the user to provide additional flags (primarily, `-Zunstable-options` to enable JSON targets).
There's a few different ways to fix this. One would be to change these calls to `rustc` to include flags provided by the user (such as `RUSTFLAGS_NOT_BOOTSTRAP`). Just to keep things simple, this PR proposes to just unconditionally pass `-Zunstable-options`.
Another consideration here is how maintainable this is. A possible improvement here would be to have a function somewhere (BootstrapCommand, TargetSelection, free function) that would handle appropriately adding the `--target` flag. For example, that's what cargo does in [`CompileKind::add_target_arg`](592058c7ce/src/cargo/core/compiler/compile_kind.rs (L144-L154)).
I have only tested building the compiler and a few tools like rustdoc. I have not tested doing things like building other tools, running tests, etc.
This would be much easier if there was a Docker image for testing the use case of building rustc with a custom target spec (and even better if that ran in CI).
After the next beta branch, using target JSON specs will become more cumbersome because target specs with the `.json` extension will now require passing `-Zjson-target-spec` (from
https://github.com/rust-lang/cargo/pull/16557). This does not affect target specs without the `.json` extension (such as those from RUST_TARGET_PATH). From my testing, it should be sufficient to pass `CARGOFLAGS_NOT_BOOTSTRAP="-Zjson-target-spec"`. I think that should be fine, since this is not a particularly common use case AFAIK. We could extend bootstrap to auto-detect if the target is a file path, and pass `-Zjson-target-spec` appropriately. I tried something similar in f0bdd35483, which could be adapted if desired.
It would be nice if all of this is documented somewhere. https://rustc-dev-guide.rust-lang.org/building/new-target.html does not really say how to build the compiler with a custom json target.
Fixes https://github.com/rust-lang/rust/issues/151729
Remove "failed to resolve" and use the same format we use in other resolution errors "cannot find `name`".
```
error[E0433]: cannot find `nonexistent` in `existent`
--> $DIR/custom_attr_multisegment_error.rs:5:13
|
LL | #[existent::nonexistent]
| ^^^^^^^^^^^ could not find `nonexistent` in `existent`
```
Improve `VaList` stdlib docs
tracking issue: https://github.com/rust-lang/rust/issues/44930
Some improvements to the `VaList` documentation, at least adding an example. We should link to the reference for c-variadic functions once stable. I've tried to call out explicitly that the type is meant for sending over the FFI boundary.
r? workingjubilee
cc @tgross35
remove `#![allow(stable_features)]` from most tests
The only remaining usages are tests that specifically deal with feature gates.
This also deletes the very weird `#![feature(issue_5723_bootstrap)]`, a 13 year old "temporary fix" (rust-lang/rust#5723).
Remove `QueryCtxt` and trait `HasDepContext`
- Follow-up to https://github.com/rust-lang/rust/pull/152636.
- Potentially waiting on https://github.com/rust-lang/rust/pull/152703 to reduce conflicts.
---
With the `QueryContext` trait removed, wrapper struct `QueryCtxt` no longer serves a purpose and can be replaced with `TyCtxt` everywhere.
After that, the only obstacle to removing trait `HasDepContext` is `DepGraph::with_task`, which uses the trait to allow passing both a `TyCtxt` and a query vtable through the context argument. But we can achieve the same result by passing the vtable through the other argument instead, in a tuple alongside the query key.
r? nnethercote
Install LLVM DLL in the right place on Windows
Continuation of https://github.com/rust-lang/rust/pull/151795 towards https://github.com/rust-lang/rust/issues/151774.
Unlike other systems, Windows requires runtime libraries to be present in `PATH` or right next to the binary.
So, we copy the library next to the binary as the easier solution.
Tested building `rust-openssl` in debug and release modes, but the difference is within noise margin.
Revert "Fix an ICE in the vtable iteration for a trait reference"
The ICE fix appears to be unsound, causing a miscompilation involving `dyn Trait` and `async {}` which induces segfaults in safe Rust code. As the patch only hid an ICE, it does not seem worth the risk.
This addresses the problem in rust-lang/rust#152735 but it may still merit team discussion even if this PR is merged.
This reverts commit 8afd63610b, reversing changes made to 19122c03c7.
This struct was only wrapping `TyCtxt` in order to implement traits that
were removed by RUST-152636.
This commit also slightly simplifies the signature of `execute_job_incr`, by
having it call `tcx.dep_graph.data()` internally.
Because:
* Something like it did not exist before PR 107404
* That it is not run our mir-opt-level 0 indicates that it is not
required for soundness
* Its `MirPass::can_be_overridden()` is unchanged and thus returns true,
indicating that it is not a required MIR pass.
* No test fails in PR 151426 that stops enabling by default in non-optimized builds
As can be seen from the updated test `tests/mir-opt/optimize_none.rs`,
this means that `#[optimize(none)]` functions become even less
optimized. As expected and as desired.
Suppress unstable-trait notes under `-Zforce-unstable-if-unmarked`
- Fixes https://github.com/rust-lang/rust/issues/152692.
---
https://github.com/rust-lang/rust/pull/151036 adds extra diagnostic text (“the nightly-only, unstable trait”) to note when a not-implemented trait is unstable.
However, that extra text is usually unhelpful when building a crate graph with `-Zforce-unstable-if-unmarked` (such as the compiler or stdlib), because *any* trait not explicitly marked stable will be treated as unstable.
(For typical compiler contributors using the stage0 compiler, this fix won't take effect until the next bootstrap beta bump.)
Fix mis-constructed `file_span` when generating scraped examples
Fixesrust-lang/rust#152601. Seemingly relative with rust-lang/rust#147399 but I could not reproduce the original ICE.
This PR removes the `file_span` logic from scraped example generation. The original implementation did not read or write items using `file_span`; it only used it to locate a source file, `context.href_from_span`. However, the span was validated against the wrong file, which could trigger ICEs on inputs such as multibyte characters due to an incorrectly constructed span. Since scraped examples do not use the span and the `url` is already given, the safest and simplest fix is to remove it.
Tested against the crate and MCVE documented in the original issue.
P.S. there seems to be some bug when rendering call sites, but since fixing mis-behavior is a change rather than a bug-fix that would be implemented in another PR.
Avoid ICE in From/TryFrom diagnostic under -Znext-solver
Fixesrust-lang/rust#152518.
Under `-Znext-solver=globally`, `trait_ref.args` may contain fewer
elements than expected. The diagnostic logic in
`fulfillment_errors.rs` assumed at least two elements and
unconditionally called `type_at(1)`, which could lead to an
index out-of-bounds panic during error reporting.
This change adds a defensive check before accessing the second
argument to avoid the ICE. A UI regression test has been added.
Implement RFC 3678: Final trait methods
Tracking: https://github.com/rust-lang/rust/issues/131179
This PR is based on rust-lang/rust#130802, with some minor changes and conflict resolution.
Futhermore, this PR excludes final methods from the vtable of a dyn Trait.
And some excerpt from the original PR description:
> Implements the surface part of https://github.com/rust-lang/rfcs/pull/3678.
>
> I'm using the word "method" in the title, but in the diagnostics and the feature gate I used "associated function", since that's more accurate.
cc @joshtriplett
The ICE fix appears to be unsound, causing a miscompilation involving
`dyn Trait` and `async {}` which induces segfaults in safe Rust code.
As the patch only hid an ICE, it does not seem worth the risk.
This reverts commit 8afd63610b, reversing
changes made to 19122c03c7.
Implement accepted ACP for `MAX_EXACT_INTEGER` and `MIN_EXACT_INTEGER`
on `f16`, `f32`, `f64`, and `f128`
Add tests to `coretests/tests/floats/mod.rs`
Disable doc tests for i586 since float<->int casts return incorrect
results
I think the previous wording as either wrong or confusing. I would
consider the CLI flags at a *lower* ranking, since source attributes are
able to override the CLI flag.
replace box_new with lower-level intrinsics
The `box_new` intrinsic is super special: during THIR construction it turns into an `ExprKind::Box` (formerly known as the `box` keyword), which then during MIR building turns into a special instruction sequence that invokes the exchange_malloc lang item (which has a name from a different time) and a special MIR statement to represent a shallowly-initialized `Box` (which raises [interesting opsem questions](https://github.com/rust-lang/rust/issues/97270)).
This PR is the n-th attempt to get rid of `box_new`. That's non-trivial because it usually causes a perf regression: replacing `box_new` by naive unsafe code will incur extra copies in debug builds, making the resulting binaries a lot slower, and will generate a lot more MIR, making compilation measurably slower. Furthermore, `vec!` is a macro, so the exact code it expands to is highly relevant for borrow checking, type inference, and temporary scopes.
To avoid those problems, this PR does its best to make the MIR almost exactly the same as what it was before. `box_new` is used in two places, `Box::new` and `vec!`:
- For `Box::new` that is fairly easy: the `move_by_value` intrinsic is basically all we need. However, to avoid the extra copy that would usually be generated for the argument of a function call, we need to special-case this intrinsic during MIR building. That's what the first commit does.
- `vec!` is a lot more tricky. As a macro, its details leak to stable code, so almost every variant I tried broke either type inference or the lifetimes of temporaries in some ui test or ended up accepting unsound code due to the borrow checker not enforcing all the constraints I hoped it would enforce. I ended up with a variant that involves a new intrinsic, `fn write_box_via_move<T>(b: Box<MaybeUninit<T>>, x: T) -> Box<MaybeUninit<T>>`, that writes a value into a `Box<MaybeUninit<T>>` and returns that box again. In exchange we can get rid of somewhat similar code in the lowering for `ExprKind::Box`, and the `exchange_malloc` lang item. (We can also get rid of `Rvalue::ShallowInitBox`; I didn't include that in this PR -- I think @cjgillot has a commit for this somewhere [around here](https://github.com/rust-lang/rust/pull/147862/commits).)
See [here](https://github.com/rust-lang/rust/pull/148190#issuecomment-3457454814) for the latest perf numbers. Most of the regressions are in deep-vector which consists entirely of an invocation of `vec!`, so any change to that macro affects this benchmark disproportionally.
This is my first time even looking at MIR building code, so I am very low confidence in that part of the patch, in particular when it comes to scopes and drops and things like that.
I also had do nerf some clippy tests because clippy gets confused by the new expansion of `vec!` so it makes fewer suggestions when `vec!` is involved.
### `vec!` FAQ
- Why does `write_box_via_move` return the `Box` again? Because we need to expand `vec!` to a bunch of method invocations without any blocks or let-statements, or else the temporary scopes (and type inference) don't work out.
- Why is `box_assume_init_into_vec_unsafe` (unsoundly!) a safe function? Because we can't use an unsafe block in `vec!` as that would necessarily also include the `$x` (due to it all being one big method invocation) and therefore interpret the user's code as being inside `unsafe`, which would be bad (and 10 years later, we still don't have safe blocks for macros like this).
- Why does `write_box_via_move` use `Box` as input/output type, and not, say, raw pointers? Because that is the only way to get the correct behavior when `$x` panics or has control effects: we need the `Box` to be dropped in that case. (As a nice side-effect this also makes the intrinsic safe, which is imported as explained in the previous bullet.)
- Can't we make it safe by having `write_box_via_move` return `Box<T>`? Yes we could, but there's no easy way for the intrinsic to convert its `Box<MaybeUninit<T>>` to a `Box<T>`. Transmuting would be unsound as the borrow checker would no longer properly enforce that lifetimes involved in a `vec!` invocation behave correctly.
- Is this macro truly cursed? Yes, yes it is.
JSON target specs were destabilized in
https://github.com/rust-lang/rust/pull/150151 and
https://github.com/rust-lang/rust/pull/151534. However, this broke
trying to build rustc itself with a JSON target spec. This is because in
a few places bootstrap is manually calling `rustc` without the ability
for the user to provide additional flags (primarily,
`-Zunstable-options` to enable JSON targets).
There's a few different ways to fix this. One would be to change these
calls to `rustc` to include flags provided by the user (such as
`RUSTFLAGS_NOT_BOOTSTRAP`). Just to keep things simple, this PR proposes
to just unconditionally pass `-Zunstable-options`.
Another consideration here is how maintainable this is. A possible
improvement here would be to have a function somewhere
(BootstrapCommand, TargetSelection, free function) that would handle
appropriately adding the `--target` flag. For example, that's what cargo
does in
[`CompileKind::add_target_arg`](592058c7ce/src/cargo/core/compiler/compile_kind.rs (L144-L154)).
I have only tested building the compiler and a few tools like rustdoc. I
have not tested doing things like building other tools, running tests,
etc.
This would be much easier if there was a Docker image for testing the
use case of building rustc with a custom target spec (and even better if
that ran in CI).
After the next beta branch, using target JSON specs will become more
cumbersome because target specs with the `.json` extension will now
require passing `-Zjson-target-spec` (from
https://github.com/rust-lang/cargo/pull/16557). This does not affect
target specs without the `.json` extension (such as those from
RUST_TARGET_PATH). From my testing, it should be sufficient to pass
`CARGOFLAGS_NOT_BOOTSTRAP="-Zjson-target-spec"`. I think that should be
fine, since this is not a particularly common use case AFAIK. We could
extend bootstrap to auto-detect if the target is a file path, and pass
`-Zjson-target-spec` appropriately. I tried something similar in
f0bdd35483,
which could be adapted if desired.
It would be nice if all of this is documented somewhere.
https://rustc-dev-guide.rust-lang.org/building/new-target.html does not
really say how to build the compiler with a custom json target.
Fixes https://github.com/rust-lang/rust/issues/151729
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#148206 (Deduplicated float tests and unified in floats/mod.rs)
- rust-lang/rust#150601 (support c-variadic functions in `rustc_const_eval`)
- rust-lang/rust#152103 (Consider captures to be used by closures that unwind)
- rust-lang/rust#152296 (Port `rust_nonnull_optimization_guaranteed` and `rustc_do_not_const_check` to the new attribute parser)
- rust-lang/rust#152648 (Remove timing assertion from `oneshot::send_before_recv_timeout`)
- rust-lang/rust#152686 (bootstrap: Inline the `is_tool` check for setting `-Zforce-unstable-if-unmarked`)
Failed merges:
- rust-lang/rust#152512 (core: Implement feature `float_exact_integer_constants`)
bootstrap: Inline the `is_tool` check for setting `-Zforce-unstable-if-unmarked`
`Mode::is_tool` is the sort of method that looks general-purpose, but is only actually used for a very specific purpose, to control the setting of `-Zforce-unstable-if-unmarked`.
It is therefore clearer to inline the mode check, which makes it easier to see how the condition affects the result.
I have tried to add some comments explaining why we set that flag, but they are based on my own recent investigations, so I'm not 100% confident that they're accurate.
Remove timing assertion from `oneshot::send_before_recv_timeout`
This test regularly spuriously fails in CI, such as https://github.com/rust-lang/rust/pull/152632#issuecomment-3902778366
We can just remove the assertion but I'd like to understand why, so I'm adding more information to the assert
Consider captures to be used by closures that unwind
Assignments to a captured variable within a diverging closure should not be considered unused if the divergence is caught.
This patch considers such assignments/captures to be used by diverging closures irrespective of whether the divergence is caught, but better a false negative unused lint than a false positive one (the latter having caused a stable-to-stable regression).
Fixesrust-lang/rust#152079
r? compiler
support c-variadic functions in `rustc_const_eval`
tracking issue: https://github.com/rust-lang/rust/issues/44930
The new `GlobalAlloc::VaList` is used to create an `AllocId` that represents the variable argument list of a frame. The allocation itself does not store any data, all we need is the unique identifier.
The actual variable argument list is stored in `Memory`, and keyed by the `AllocId`. The `Frame` also stores this `AllocId`, so that when a frame is popped, it can deallocate the variable arguments.
At "runtime" a `VaList` value stores a pointer to the global allocation in its first bytes. The provenance on this pointer can be used to retrieve its `AllocId`, and the offset of the pointer is used to store the index of the next argument to read from the variable argument list.
Miri does not yet support `va_arg`, but I think that can be done separetely?
r? @RalfJung
cc @workingjubilee
Deduplicated float tests and unified in floats/mod.rs
In this PR Float tests are deduplicated and are unified in floats/mod.rs, as discussed in https://github.com/rust-lang/rust/issues/141726.
The moved float tests are:
-> test_powf
-> test_exp
-> test_exp2
-> test_ln
-> test_log_generic
-> test_log2
-> test_log10
-> test_asinh
-> test_acosh
-> test_atanh
-> test_gamma
-> test_ln_gamma
Closes: https://github.com/rust-lang/rust/issues/141726
From `rustc_query_system` to `rustc_middle.` I put it in `graph.rs`,
it's one of two files that uses `QuerySideEffect` and seemed as good as
anywhere else.
Big query system cleanups
Recent PRs have moved a lot of code from `rustc_query_system` to `rustc_middle` and `rustc_query_impl`, where this code now has access to `TyCtxt`, e.g. rust-lang/rust#152419, rust-lang/rust#152516. As a result, a lot of abstraction and indirection that existed to work around this limitation is no longer necessary. This PR removes a lot of it.
r? @Zalathar
feat: show what lint was overruled
We can't `#[allow]` a whole lint group if any of its members is forbidden, but the offending member is not currently shown if it was forbidden from the command line.
Before/after:
```diff
$ rustc -F dead_code - <<< '#![allow(unused)]'
error[E0453]: allow(unused) incompatible with previous forbid
--> <anon>:1:10
|
1 | #![allow(unused)]
| ^^^^^^ overruled by previous forbid
|
- = note: `forbid` lint level was set on command line
+ = note: `forbid` lint level was set on command line (`-F dead_code`)
error: aborting due to 1 previous error
```
@rustbot label +A-diagnostics +A-lints +D-terse
New float tests in core are failing on clif with issues like the
following:
Undefined symbols for architecture arm64:
"_coshf128", referenced from:
__RNvMNtCshY0fR2o0hOA_3std4f128C4f1284coshCs5TKtJxXQNGL_9coretests in coretests-e38519c0cc90db54.coretests.44b6247a565e10d1-cgu.10.rcgu.o
"_exp2f128", referenced from:
__RNvMNtCshY0fR2o0hOA_3std4f128C4f1284exp2Cs5TKtJxXQNGL_9coretests in coretests-e38519c0cc90db54.coretests.44b6247a565e10d1-cgu.10.rcgu.o
...
Disable f128 math unless the symbols are known to be available, which
for now is only glibc targets. This matches the LLVM backend.
Fix const normalization for generic const items with trait assoc consts
In `try_fold_free_or_assoc`, the check for whether the normalization result needs further normalization only considered types, not constants. This caused generic const items marked with `#[type_const]` that reference trait associated consts to only partially normalize—the outer const would be expanded, but the inner associated const would remain unevaluated, resulting in an ICE in borrowck.
closerust-lang/rust#151647
r? BoxyUwU
(Based on git blame)
Pass alignments through the shim as `Alignment` (not `usize`)
We're using `Layout` on both sides, so might as well skip the transmutes back and forth to `usize`.
The mir-opt test shows that doing so allows simplifying the boxed-slice drop slightly, for example.
Unlike other systems, Windows requires runtime libraries to be present
in `PATH` or right next to the binary.
So, we copy the library next to the binary as the easier solution.
the rhs of an ordinary assignment `x = *never_ptr` was inferred with
`ExprIsRead::No`, which prevented `NeverToAny` coercion for place
expressions of type `!`. this caused false type mismatches and missing
divergence detection. the destructuring assignment path and let binding
path both correctly use `ExprIsRead::Yes` for the rhs value, since the
value is always consumed (read). this makes the ordinary assignment path
consistent with both.
It was just a dummy implementation to workarround the fact that thin
local lto is the default in rustc. By adding a thin_lto_supported thin
local lto can be automatically disabled for cg_gcc, removing the need
for this dummy implementation. This makes improvements to the LTO
handling on the cg_ssa side a lot easier.
Use `scope` for `par_slice` instead of `join`
This uses `scope` instead of nested `join`s in `par_slice` so that each group of items are independent and do not end up blocking on another.
unwind/wasm: fix compile error by wrapping wasm_throw in unsafe block
This fix rust-std compile error on wasm32-unknown-unknown with panic=unwind because of `#![deny(unsafe_op_in_unsafe_fn)]`
Add regression test for #141738Closesrust-lang/rust#141738
- Add a regression test for rust-lang/rust#141738
- Using a struct constructor (`DefKind::Ctor(Struct, Const)`) as an array repeat count with `#![feature(min_generic_const_args)]` used to ICE in const alias normalization
- Fixed by rust-lang/rust#150704, which added const constructor support for mGCA. This test covers the **error path** (struct ctor where `usize` is expected), which was not covered by the tests in rust-lang/rust#150704
Include `library/stdarch` for `CURRENT_RUSTC_VERSION` updates
Our tool `replace-version-placeholder` uses the `tidy` file walker and its
directory filter, but that skips `library/stdarch` which we do need for public
stability markers. This PR adds a local filter function that explicitly allows
that path.
The commit for 1.94 `stdarch` updates is coming from beta rust-lang/rust#152187.
ci: Lock cross toolchain version and update docs
This PR locks the cross-toolchain component version to avoid unexpected changes when bumping crosstool-ng, and updates the toolchain configuration in the docs to match the actual setup.
try-job: dist-arm-linux-musl
try-job: dist-loongarch64-linux
try-job: dist-loongarch64-musl
try-job: dist-powerpc64-linux-musl
try-job: dist-powerpc64le-linux-gnu
try-job: dist-powerpc64le-linux-musl
Test(lib/win/net): Skip UDS tests when under Win7
Unix Domain Socket support has only been added to Windows since Windows 10 Insider Preview Build 17063. Thus, it has no chance of ever being supported under Windows 7, making current tests fail. This therefore adds the necessary in order to make the tests dynamically skip when run under Windows 7, 8, and early 10, as it does not trigger linker errors.
cc rust-lang/rust#150487 @roblabla
@rustbot label T-libs A-io O-windows-7
Improve write! and writeln! error when called without destination
Fixesrust-lang/rust#152493
Adds catch-all arms to `write!` and `writeln!` macros so that calling them without a destination (e.g., `write!("S")` instead of `write!(f, "S")`) gives a clear error instead of the cryptic "unexpected end of macro invocation" pointing at macro internals.
r? @estebank
implement `carryless_mul`
tracking issue: https://github.com/rust-lang/rust/issues/152080
ACP: https://github.com/rust-lang/libs-team/issues/738
This defers to LLVM's `llvm.clmul` when available, and otherwise falls back to a method from the `polyval` crate ([link](https://github.com/RustCrypto/universal-hashes/blob/master/polyval/src/field_element/soft/soft64.rs)).
Some things are missing, which I think we can defer:
- the ACP has some discussion about additional methods, but I'm not sure exactly what is wanted or how to implement it efficiently
- the SIMD intrinsic is not yet `const` (I think I ran into a bootstrapping issue). That is fine for now, I think in `stdarch` we can't really use this intrinsic at the moment, we'd only want the scalar version to replace some riscv intrinsics.
- the SIMD intrinsic is not implemented for the gcc and cranelift backends. That should be reasonably straightforward once we have a const eval implementation though.
diagnostics: add note when param-env shadows global impl
This PR adds a diagnostics note when param-env shadows global impl as discussed in https://github.com/rust-lang/rust/issues/149910
It adds a note explaining that the definition is hidden by the generic bound.
r?lcnr
By removing the generic `D` parameter from `DepGraph`, `DepGraphData`,
`CurrentDepGraph`, `SerializedDepGraph`, `SerializedNodeHeader`, and
`EncoderState`.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#152622 (Update GCC subtree)
- rust-lang/rust#145024 (Optimize indexing slices and strs with inclusive ranges)
- rust-lang/rust#151365 (UnsafePinned: implement opsem effects of UnsafeUnpin)
- rust-lang/rust#152381 (Do not require `'static` for obtaining reflection information.)
- rust-lang/rust#143575 (Remove named lifetimes in some `PartialOrd` & `PartialEq` `impl`s)
- rust-lang/rust#152404 (tests: adapt align-offset.rs for InstCombine improvements in LLVM 23)
- rust-lang/rust#152582 (rustc_query_impl: Use `ControlFlow` in `visit_waiters` instead of nested options)
the standalone `contains_explicit_ref_binding` function only checked for
`BindingAnnotation::Ref`, missing `BindingAnnotation::RefMut`. this caused
`let ref mut x = expr` to incorrectly take the coercion path instead of
preserving the exact type of the rhs expression. the method version used
for match arms already handles both `Ref` and `RefMut` correctly.
tests: adapt align-offset.rs for InstCombine improvements in LLVM 23
Upstream [has improved InstCombine](8d2078332c) so that it can shrink added constants using known zeroes, which caused a little bit of change in this test. As far as I can tell either output is fine, so we just accept both.
@rustbot label: +llvm-main
Do not require `'static` for obtaining reflection information.
tracking issue rust-lang/rust#142577
This does not affect the stable `TypeId::of`, as that has its own `'static` bound.
But it will allow obtaining `TypeId`s for non-static types via the reflection API. To obtain such a `TypeId` for any type, just use `Type::of::<(T,)>().kind` to extract the first field of a tuple.
This effectively reintroduces rust-lang/rust#41875, which @rust-lang/lang decided against allowing back in 2018 due to lack of sound use cases. We will thus need to have a T-lang meeting specifically about `TypeId` for non-static types before *stabilizing* any part of reflection (in addition to T-lang meetings about reflection in general). I'm adding an explicit point about this to the tracking issue.
cc @scottmcm @joshtriplett @9SonSteroids @SpriteOvO @izagawd @BD103
UnsafePinned: implement opsem effects of UnsafeUnpin
This implements the next step for https://github.com/rust-lang/rust/issues/125735: actually making `UnsafePinned` have special opsem effects by suppressing the `noalias` *even if* the type is wrapped in an `Unpin` wrapper.
For backwards compatibility we also still keep the `Unpin` hack, i.e. a type must be both `Unpin` and `UnsafeUnpin` to get `noalias`.
Optimize indexing slices and strs with inclusive ranges
Instead of separately checking for `end == usize::MAX` and `end + 1 > slice.len()`, we can check for `end >= slice.len()`. Also consolidate all the str indexing related panic functions into a single function which reports the correct error depending on the arguments, as the slice indexing code already does.
The downside of all this is that the panic message is slightly less specific when trying to index with `[..=usize::MAX]`: instead of saying "attempted to index str up to maximum usize" it just says "end byte index {end} out of bounds". But this is a rare enough case that I think it is acceptable
the command 'cargo build --no-default-features --features borsh' failed with:
error[E0599]: no function or associated item named 'other' found for struct 'borsh::io::Error' in the current scope
--> lib/smol_str/src/borsh.rs:33:39
|
33 | .ok_or_else(|| Error::other("u8::vec_from_reader unexpectedly returned None"))?;
| ^^^^^ function or associated item not found in 'borsh::io::Error'
|
Using a struct constructor (DefKind::Ctor(Struct, Const)) as an array
repeat count with `#![feature(min_generic_const_args)]` used to trigger
an ICE in const alias normalization. Add a regression test to ensure
the compiler produces a proper type error instead of panicking.
DepGraphQuery: correctly skip adding edges with not-yet-added nodes
Fixes https://github.com/rust-lang/rust/issues/142152.
The current logic already skips some edges, so I'm not sure how critical it is to have *all* the edges recorded, the logic seems to only be used for debug dumping.
Recording all edges requires supporting holes in the `LinkedGraph` data structure, to add nodes and edges out of order, https://github.com/rust-lang/rust/pull/151821 implements that at cost of complicating the data structure.
Port #[rustc_test_marker] to the attribute parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
Targets:
Const is for normal tests (const test::TestDescAndFn is inserted before the test fn)
Const/Static/Fn is for custom_test_framework's #[test_case] e.g. tests/ui/custom_test_frameworks/full.rs
r? @JonathanBrouwer
Again I left the use-sites as is since they are early uses.
Don't ICE on layout error in vtable computation
Fixesrust-lang/rust#152030.
Note: I'm including a more general testcase that doesn't use the feature in the original report, but only reproduces with debuginfo disabled. Does it make sense to also include the original testcase?
Make operational semantics of pattern matching independent of crate and module
The question of "when does matching an enum against a pattern of one of its variants read its discriminant" is currently an underspecified part of the language, causing weird behavior around borrowck, drop order, and UB.
Of course, in the common cases, the discriminant must be read to distinguish the variant of the enum, but currently the following exceptions are implemented:
1. If the enum has only one variant, we currently skip the discriminant read.
- This has the advantage that single-variant enums behave the same way as structs in this regard.
- However, it means that if the discriminant exists in the layout, we can't say that this discriminant being invalid is UB. This makes me particularly uneasy in its interactions with niches – consider the following example ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=5904a6155cbdd39af4a2e7b1d32a9b1a)), where miri currently doesn't detect any UB (because the semantics don't specify any):
<details><summary>Example 1</summary>
```rust
#![allow(dead_code)]
use core::mem::{size_of, transmute};
#[repr(u8)]
enum Inner {
X(u8),
}
enum Outer {
A(Inner),
B(u8),
}
fn f(x: &Inner) {
match x {
Inner::X(v) => {
println!("{v}");
}
}
}
fn main() {
assert_eq!(size_of::<Inner>(), 2);
assert_eq!(size_of::<Outer>(), 2);
let x = Outer::B(42);
let y = &x;
f(unsafe { transmute(y) });
}
```
</details>
2. For the purpose of the above, enums with marked with `#[non_exhaustive]` are always considered to have multiple variants when observed from foreign crates, but the actual number of variants is considered in the current crate.
- This means that whether code has UB can depend on which crate it is in: https://github.com/rust-lang/rust/issues/147722
- In another case of `#[non_exhaustive]` affecting the runtime semantics, its presence or absence can change what gets captured by a closure, and by extension, the drop order: https://github.com/rust-lang/rust/issues/147722#issuecomment-3674554872
- Also at the above link, there is an example where removing `#[non_exhaustive]` can cause borrowck to suddenly start failing in another crate.
3. Moreover, we currently make a more specific check: we only read the discriminant if there is more than one *inhabited* variant in the enum.
- This means that the semantics can differ between `foo<!>`, and a copy of `foo` where `T` was manually replaced with `!`: rust-lang/rust#146803
- Moreover, due to the privacy rules for inhabitedness, it means that the semantics of code can depend on the *module* in which it is located.
- Additionally, this inhabitedness rule is even uglier due to the fact that closure capture analysis needs to happen before we can determine whether types are uninhabited, which means that whether the discriminant read happens has a different answer specifically for capture analysis.
- For the two above points, see the following example ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=a07d8a3ec0b31953942e96e2130476d9)):
<details><summary>Example 2</summary>
```rust
#![allow(unused)]
mod foo {
enum Never {}
struct PrivatelyUninhabited(Never);
pub enum A {
V(String, String),
Y(PrivatelyUninhabited),
}
fn works(mut x: A) {
let a = match x {
A::V(ref mut a, _) => a,
_ => unreachable!(),
};
let b = match x {
A::V(_, ref mut b) => b,
_ => unreachable!(),
};
a.len(); b.len();
}
fn fails(mut x: A) {
let mut f = || match x {
A::V(ref mut a, _) => (),
_ => unreachable!(),
};
let mut g = || match x {
A::V(_, ref mut b) => (),
_ => unreachable!(),
};
f(); g();
}
}
use foo::A;
fn fails(mut x: A) {
let a = match x {
A::V(ref mut a, _) => a,
_ => unreachable!(),
};
let b = match x {
A::V(_, ref mut b) => b,
_ => unreachable!(),
};
a.len(); b.len();
}
fn fails2(mut x: A) {
let mut f = || match x {
A::V(ref mut a, _) => (),
_ => unreachable!(),
};
let mut g = || match x {
A::V(_, ref mut b) => (),
_ => unreachable!(),
};
f(); g();
}
```
</details>
In light of the above, and following the discussion at rust-lang/rust#138961 and rust-lang/rust#147722, this PR ~~makes it so that, operationally, matching on an enum *always* reads its discriminant.~~ introduces the following changes to this behavior:
- matching on a `#[non_exhaustive]` enum will always introduce a discriminant read, regardless of whether the enum is from an external crate
- uninhabited variants now count just like normal ones, and don't get skipped in the checks
As per the discussion below, the resolution for point (1) above is that it should land as part of a separate PR, so that the subtler decision can be more carefully considered.
Note that this is a breaking change, due to the aforementioned changes in borrow checking behavior, new UB (or at least UB newly detected by miri), as well as drop order around closure captures. However, it seems to me that the combination of this PR with rust-lang/rust#138961 should have smaller real-world impact than rust-lang/rust#138961 by itself.
Fixesrust-lang/rust#142394Fixesrust-lang/rust#146590Fixesrust-lang/rust#146803 (though already marked as duplicate)
Fixes parts of rust-lang/rust#147722Fixesrust-lang/miri#4778
r? @Nadrieril @RalfJung
@rustbot label +A-closures +A-patterns +T-opsem +T-lang
We're using `Layout` on both sides, so might as well skip the transmutes back and forth to `usize`.
The mir-opt test shows that doing so allows simplifying the boxed-slice drop slightly, for example.
Most of the files within the `dep_graph` module can be moved wholesale
into `rustc_middle`. But two of them (`mod.rs` and `dep_node.rs`) have
the same name as existing files in `rustc_middle`, so for those I just
copied the contents into the existing files.
The commit also moves `QueryContext` and `incremental_verify_ich*`
because they are tightly intertwined with the dep graph code. And a
couple of error structs moved as well.
This includes the types `QueryInfo`, `QueryJob`, `QueryJobId`,
`QueryWaiter`, `QueryLatch`, and `QueryLatchInfo`.
`CycleError` and `QueryStack*` had to come along too, due to type
interdependencies. The `QueryStack*` types are put into a new submodule
`rustc_middle::query::stack`.
A couple of tiny polonius things
Here's a couple of tiny things I had ready to go @jackh726
- a tiny cleanup to avoid round-tripping through `Location`s to check for liveness, since we're already working with points
- while I was there, I fixed the doc which wasn't showing up properly (maybe a rustdoc or bootstrap bug when we build locally or during dist, either way, both don't show up correctly linked most of the time) for `PointIndex`es.
- and in the second commit slightly expand test coverage with [an example](https://internals.rust-lang.org/t/get-mut-map-back-from-entry-api/24003) that would have needed stdlib changes (cc author @Darksonn for visibility here)
More soon.
r? @jackh726
rustdoc: more js cleanup
Continuing the effort of removing `@ts-expect-error` from the codebase wherever possible, this time focusing on `main.js`. Found some oddities with `register_type_impls`, fixed most of them, but the one that I couldn't figure out is what's going on with `sidebarTraitList`. It's queried, then if there are any trait imps, unconditionally overwritten, then latter code assumes that one of these two things has initialized it, but it's not obvious why this would be the case, or if there's a reason this wasn't done in a more straightforwards way.
r? @GuillaumeGomez
improve associated-type suggestions from bounds
Should address invalid suggestions I could come up with, but the suggestion is too hand-crafted and invalid patterns may exist.
r? @estebank
Fix https://github.com/rust-lang/rust/issues/73321
Feed `ErrorGuaranteed` from late lifetime resolution errors through to bound variable resolution
If late lifetime resolution fails for whatever reason, forward to RBV the guarantee that an error was emitted - thereby eliminating the need for a "hack" to suppress subsequent/superfluous error diagnostics.
Fixesrust-lang/rust#152014
r? fmease
rustdoc: sort stable items first
Finally tackling this again now that the search system refactor is done. The tests and the general approach were taken from the original PR.
Set hidden visibility on naked functions in compiler-builtins
88b46460fa made builtin functions hidden, but it doesn't apply to naked functions, which are generated through a different code path.
This was discovered in rust-lang/rust#151486 where aarch64 outline atomics showed up in shared objects, overriding the symbols from compiler-rt.
Unix Domain Socket support has only been added to Windows since Windows
10 Insider Preview Build 17063. Thus, it has no chance of ever being
supported under Windows 7, making current tests fail. This therefore
adds the necessary in order to make the tests dynamically skip when run
under Windows 7, 8, and early 10, as it does not trigger linker errors.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
Rollup of 14 pull requests
Successful merges:
- rust-lang/rust#152323 (Fix ICE in borrowck when recovering `fn_sig` for `-> _`)
- rust-lang/rust#152469 (Remove unused features)
- rust-lang/rust#152515 (Extract `DepKindVTable` constructors to their own module)
- rust-lang/rust#152555 (Port `#[rustc_diagnostic_item]` to the new attribute parsers)
- rust-lang/rust#152218 (Report unconstrained region in hidden types lazily)
- rust-lang/rust#152356 (Improve the `inline_fluent!` macro)
- rust-lang/rust#152392 (Fix ICE in supertrait_vtable_slot when supertrait has missing generics)
- rust-lang/rust#152407 (Add regression test for type_const with unit struct ctor under mGCA)
- rust-lang/rust#152440 (Fix typos and grammar in compiler and build documentation)
- rust-lang/rust#152536 (bootstrap: add explicit UTF-8 encoding to text-mode open() calls)
- rust-lang/rust#152554 (Remove `deprecated_safe` and its corresponding feature gate)
- rust-lang/rust#152556 (doc: move riscv64a23-unknown-linux-gnu to tier 2)
- rust-lang/rust#152563 (Replace "bug" with "issue" in triagebot ping messages)
- rust-lang/rust#152565 (fix missleading error for tuple ctor)
Failed merges:
- rust-lang/rust#152512 (core: Implement feature `float_exact_integer_constants`)
- rust-lang/rust#152296 (Port `rust_nonnull_optimization_guaranteed` and `rustc_do_not_const_check` to the new attribute parser)
If late lifetime resolution fails for whatever reason, forward to RBV
the guarantee that an error was emitted - thereby eliminating the need
for a "hack" to suppress subsequent/superfluous error diagnostics.
doc: move riscv64a23-unknown-linux-gnu to tier 2
This updates the platform support documentation to reflect that "riscv64a23-unknown-linux-gnu" is now Tier 2.
-Docs-only change (no compiler/runtime behavior change).
Fixesrust-lang/rust#152539
Remove `deprecated_safe` and its corresponding feature gate
This unimplements the feature gate for tracking issue https://github.com/rust-lang/rust/issues/94978
The author of that tracking issue and the MCP seem to no longer exist
Afaik we can just do this, but let me know if I'm wrong
Because this feature has been idle for 3+ years, and it is in the way to finish the attribute refactoring (https://github.com/rust-lang/rust/issues/131229#issuecomment-2971351163)
When someone wants to do work on it the feature gate can be re-added
r? @jdonszelmann
bootstrap: add explicit UTF-8 encoding to text-mode open() calls
Make text-mode `open()` calls in `bootstrap.py`
explicitly use `encoding="utf-8"`.
This avoids relying on platform-dependent default encodings
when running Python < 3.15.
Binary-mode opens remain unchanged.
Extract `DepKindVTable` constructors to their own module
This is a fairly substantial chunk of code in `rustc_query_impl::plumbing` that mostly doesn't need to be inside a macro at all.
The part that does need to be in a macro is the declaration of a named vtable constructor function for each query. I have extracted that into its own separate call to `rustc_middle::rustc_with_all_queries!` in the new module, so that dep-kind vtable construction is almost entirely confined to `rustc_query_impl::dep_kind_vtables`.
There should be no change to compiler behaviour.
r? nnethercote (or compiler)
Add 2048-bit HvxVectorPair support to Hexagon SIMD ABI checks
Previously, rustc rejected HvxVectorPair types in function signatures because the HEXAGON_FEATURES_FOR_CORRECT_FIXED_LENGTH_VECTOR_ABI array only had entries for vectors up to 1024 bits. This caused the ABI checker to emit "unsupported vector type" errors for 2048-bit HvxVectorPair (used in 128-byte HVX mode).
Add 2048 byte entry to allow HvxVectorPair to be passed in extern "C" funcs when the hvx-length128b is enabled.
sparc64: enable abi compatibility test
fixes https://github.com/rust-lang/rust/issues/115336
We can now remove the exceptions for sparc64 from the abi compatibility tests (since https://github.com/rust-lang/rust/pull/142680).
I was also able to remove a cfg for mips64. The remaining (tested) issues seem to be around how `f64` is handled there.
cc @RalfJung
r? tgross35
Don't use `DepContext` in `rustc_middle::traits::cache`
- A nice little simplification unlocked by https://github.com/rust-lang/rust/pull/152199.
---
This code is now in `rustc_middle`, and doesn't need any non-trivial methods, so it can just use `TyCtxt` directly instead.
Collect active query jobs into struct `QueryJobMap`
This PR encapsulates the existing `QueryMap` type alias into a proper struct named `QueryJobMap`, which is used by code that wants to inspect the full set of currently-active query jobs.
Wrapping the query job map in a struct makes it easier to see how other code interacts with the map, and also lets us change some free functions for map lookup into methods.
We also do a renaming pass to consistently refer to the query job map as `job_map`, or as `job_map_out` in the places where it's a mutable out-parameter.
There should be no change to compiler behaviour.
r? nnethercote (or compiler)
Change query proc macro to be more rust-analyzer friendly
This changes the query proc macro to be more rust-analyzer friendly.
- Types in the macro now have a proper span
- Some functions have their span hidden so they don't show up when hovering over the query name
- Added a hint on the provider field on how to find providers. That is shown when hovering over the query name
- Linked query name to the provider field on all queries, not just ones with caching
- Added tooltip for the query modifiers by linking to the new types in `rustc_middle:::query::modifiers`
Compute localized outlives constraints lazily
This PR rewrites the loan liveness algorithm to compute localized constraints lazily during traversal, to avoid the sometimes costly conversion and indexing happening in the current eager algorithm (or for now as well, the need to reshape the liveness data to better list regions live at a given point).
It thus greatly reduces the current alpha overhead, although it wasn't entirely removed of course (we're obviously doing more work to improve precision): the worst offending benchmark has a +5-6% wall-time regression — but icounts are worse looking (+13%) rn.
Best reviewed per-commit, as steps are in sequence to simplify the process or unify some things.
r? @jackh726
Previously, rustc rejected HvxVectorPair types in function signatures
because the HEXAGON_FEATURES_FOR_CORRECT_FIXED_LENGTH_VECTOR_ABI array
only had entries for vectors up to 1024 bits. This caused the ABI checker
to emit "unsupported vector type" errors for 2048-bit HvxVectorPair
(used in 128-byte HVX mode).
Add 2048 byte entry to allow HvxVectorPair to be passed
in extern "C" funcs when the hvx-length128b is enabled.
now that we need to hold the graph for MIR dumping, and the associated
data to traverse it, there is no difference between the main context and
diagnostics context, so we merge them.
we may need to traverse the lazy graph multiple times:
- to record loan liveness
- to dump the localized outlives constraint in the polonius MIR dump
to do that we extract the previous loan liveness code into an abstract
traversal + visitor handling the liveness-specific parts, while the MIR
dump will be able to record constraints in its own visitor.
now that the analysis is only using the regular liveness shape, we don't
need to store it transposed, and thus don't need the container where it
was stored: the liveness context would be alone in the polonius context.
we thus remove the latter, and rename the former.
Update cargo submodule
8 commits in 0c9e687d237ff04b53ccb67b4ce63e9483789e88..ce69df6f72a3b6a2b5c722ba68ddef255344b31c
2026-02-11 05:58:30 +0000 to 2026-02-12 12:39:45 +0000
- fix: apply `host.runner` only when `host-config` enabled (rust-lang/cargo#16631)
- fix(cli): Improve bad manifest error (rust-lang/cargo#16630)
- fix: Adjust casing of error message (rust-lang/cargo#16625)
- Enable triagebot new `[view-all-comments-link]` feature (rust-lang/cargo#16629)
- test(help): snapshot cargo help tests (rust-lang/cargo#16626)
- Suggest a `workspace.members` entry even from outside the workspace root (rust-lang/cargo#16616)
- Reorganize build unit directory layout for new build-dir layout (rust-lang/cargo#16542)
- Make the error messaging for `cargo install` aware of `build.build-dir` (rust-lang/cargo#16623)
The compiler is fixing a bug [1] that Rust for Linux happened to trigger,
thus temporarily add Benno's patch to the CI job.
As usual, the patch will eventually make it to the Linux kernel so that
both sides are good.
Cc: Benno Lossin <lossin@kernel.org>
Link: https://github.com/rust-lang/rust/pull/149389 [1]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Start using pattern types in libcore (NonZero and friends)
part of rust-lang/rust#136006
This PR only changes the internal representation of `NonZero`, `NonMax`, ... and other integral range types in libcore. This subsequently affects other types made up of it, but nothing really changes except that the field of `NonZero` is now accessible safely in contrast to the `rustc_layout_scalar_range_start` attribute, which has all kinds of obscure rules on how to properly access its field.
llvm will look at both
1. the values of "target-features" and
2. the function string attributes.
this removes the redundant function string attribute because it is not needed at all.
rustc sets the `+backchain` attribute through `target_features_attr(...)`
Implement `BinaryHeap::from_raw_vec`
Implements rust-lang/rust#152500.
Adds a `BinaryHeap::from_raw_vec` function, which constructs a `BinaryHeap` without performing a heapify, for data that is already a max-heap.
Clean up some subdiagnostics
Just a nice minor cleanup :)
* Removes some empty subdiagnostics which could just be subdiagnostic attributes
* Convert some manual implementation of `Subdiagnostic` to derives
Correctly check if a macro call is actually a macro call in rustdoc highlighter
Fixesrust-lang/rust#151904.
Issues was that if there was a `!` following an ident, we would always assume it's a macro call... except it's very lacking. I'm actually surprised it went for so long unnoticed. To fix it, I added a check for the next (non-blank) token after the `!`, if it's a `{` or a `[` or a `(`, then only do we consider it to be a macro call.
r? @lolbinarycat
Clarify names of `QueryVTable` functions for "executing" a query
In the query system, there are several layers of functions involved in “executing” a query, with very different responsibilities at each layer, making it important to be able to tell them apart.
This PR renames two of the function pointers in `QueryVTable`, along with their associated helper functions, to hopefully do a better job of indicating what their actual responsibilities are.
r? nnethercote
Borrowck: simplify diagnostics for placeholders
This folds the call to `region_from_element` into `RegionInferenceContext`, and simplifies the error variant for this case to only talk about regions as opposed to elements. This is the only case where a `RegionElement` leaks out of region inference, so now they can be considered internal to region inference (though that currently isn't expressed). It also clarifies the type information on the methods called to emphasise the fact that they only ever use placeholder regions in the diagnostics completely ignore any other element.
It also adds a bunch of FIXMEs to some fishy statements that conjure universes from what seems like arbitrary integers.
This was lifted from rust-lang/rust#142623.
r? @lcnr
Don't compute FnAbi for LLVM intrinsics in backends
~~This removes support for `extern "unadjusted"` for anything other than LLVM intrinsics. It only makes sense in the context of calling LLVM intrinsics anyway as it exposes the way the LLVM backend internally represents types. Perhaps it should be renamed to `extern "llvm-intrinsic"`?~~
Follow up to https://github.com/rust-lang/rust/pull/148533
Add FCW for derive helper attributes that will conflict with built-in attributes
Adds a future-compatibility-warning deny-by-default lint that helps catch invalid derive helper attribute names early.
This issues the lint, saying that `ignore` helper will clash with the built-in `ignore` attribute.
```rust
#![crate_type = "proc-macro"]
#![deny(ambiguous_derive_helpers)]
use proc_macro::TokenStream;
#[proc_macro_derive(Trait, attributes(ignore))]
pub fn example(input: TokenStream) -> TokenStream {
TokenStream::new()
}
```
If you actually tried to use that `ignore` helper attribute, you won't be able to due to the ambiguity:
```rust
#[derive(Trait)]
struct Foo {
#[ignore]
field: (),
}
```
Produces:
```
error[E0659]: `ignore` is ambiguous
--> src/lib.rs:5:7
|
5 | #[ignore]
| ^^^^^^ ambiguous name
|
= note: ambiguous because of a name conflict with a builtin attribute
= note: `ignore` could refer to a built-in attribute
note: `ignore` could also refer to the derive helper attribute defined here
--> src/lib.rs:3:10
|
3 | #[derive(Trait)]
| ^^^^^
```
Don't compute FnAbi for LLVM intrinsics in backends
~~This removes support for `extern "unadjusted"` for anything other than LLVM intrinsics. It only makes sense in the context of calling LLVM intrinsics anyway as it exposes the way the LLVM backend internally represents types. Perhaps it should be renamed to `extern "llvm-intrinsic"`?~~
Follow up to https://github.com/rust-lang/rust/pull/148533
Support ADT types in type info reflection
Tracking issue: rust-lang/rust#146922 `#![feature(type_info)]`
This PR supports ADT types for feature `type_info` reflection.
(It's still a draft PR, with implementation in progress)
Note that this PR does not take SemVer into consideration (I left a FIXME comment). As discussed earlier ([comment](https://github.com/rust-lang/rust/pull/146923#discussion_r2372249477)), this requires further discussion. However, I hope we could get an initial implementation to land first, so we can start playing with it.
### Progress / Checklist
- [x] Struct support.
- [x] Enum
- [x] Union
- [x] Generics
- [ ] ~Methods~ Implemented and to be implemented in other PRs
- [ ] ~Traits~ Implemented and to be implemented in other PRs
- [x] Rebasing PR to `main` branch
~~(It's currently based on PR rust-lang/rust#151123, so here's an extra commit)~~
- [x] Cleanup and Rebase.
- [x] Fix field info for references. (see [comment](https://github.com/rust-lang/rust/pull/151142#discussion_r2777920512))
r? @oli-obk
borrowck: suggest `&mut *x` for pattern reborrows
Fixesrust-lang/rust#81059
r? @estebank as you should have some context here, but feel free to re-assign if you don't have time to review right now.
Triagebot implemented a GitHub comments viewer, it loads and shows all
the comments (and review comments) of an issue or pull-request.
In order to facilitate it's usage we also added a feature to
automatically have triagebot add a "View all comments" link to that
viewer, which this PR enables for this repository with a threshold of 20
comments minimum.
See [this
link](https://triage.rust-lang.org/gh-comments/rust-lang/rust-clippy/issues/15006)
for an example of the result looks like.
cc @samueltardieu
r? @flip1995
changelog: none
Marking the `main` function as `#[must_use]` is nonsensical, as it is
not really supposed to be called anyway.
changelog: [`must_use_candidates`]: No longer lints `main` functions
with return values
Update books
## rust-lang/book
1 commits in 39aeceaa3aeab845bc4517e7a44e48727d3b9dbe..05d114287b7d6f6c9253d5242540f00fbd6172ab
2026-02-03 15:19:04 UTC to 2026-02-03 15:19:04 UTC
- Temporarily remove the link to `Drop::drop` (rust-lang/book#4576)
## rust-lang/nomicon
1 commits in 050c002a360fa45b701ea34feed7a860dc8a41bf..b8f254a991b8b7e8f704527f0d4f343a4697dfa9
2026-01-29 12:15:01 UTC to 2026-01-29 12:15:01 UTC
- Fix deprecation warning for compare_and_swap in atomics.md (rust-lang/nomicon#519)
## rust-lang/reference
12 commits in 990819b86c22bbf538c0526f0287670f3dc1a67a..addd0602c819b6526b9cc97653b0fadca395528c
2026-02-04 14:35:59 UTC to 2026-01-26 18:02:14 UTC
- const-eval.const-expr.field: make paragraph more clear (rust-lang/reference#2157)
- make more clear what the link target is (rust-lang/reference#2156)
- Update two URLs (rust-lang/reference#2154)
- Add a chapter on divergence (rust-lang/reference#2067)
- Guarantee `repr(C)` union field offset (rust-lang/reference#2128)
- Reference updates for forbidding object lifetime changing pointer casts (rust-lang/reference#1951)
- Clarify only arrays undergo unsized coercion during dispatch (rust-lang/reference#2139)
- Split the textual chapter into separate char and str chapters (rust-lang/reference#2145)
- Document ppc inline asm support (rust-lang/reference#2056)
- Unwrap items, expressions, patterns, and types (rust-lang/reference#2141)
- undefined behavior: add missing plural in `undefined.misaligned.ptr` (rust-lang/reference#2146)
- inline-assembly: add a space to the `asm.abi-clobbers.many` example (rust-lang/reference#2144)
BikeshedGuaranteedNoDrop trait: add comments indicating that it can be observed on stable
Not sure if that's worth it, maybe this goes without saying for all these builtin traits?
style: remove unneeded trailing commas
Make format-like macro calls look similar to what `cargo fmt` does automatically - remove trailing commas. When removing a comma, I also inlined some variables for consistency and clarity.
I'm working on a [clippy lint](https://github.com/rust-lang/rust-clippy/pull/16530) to make this process automatic.
Move more query system code
Towards the goal of eliminating `rustc_query_system`, this commit moves some code from `rustc_query_system` to `rustc_middle` and `rustc_query_impl`, and from `rustc_middle` to `rustc_query_impl`.
r? @Zalathar
Rename `into_range` to `try_into_slice_range`:
- Prepend `try_` to show that it returns `None` on error, like `try_range`
- add `_slice` to make it consistent with `into_slice_range`
The panic message when slicing a string with a negative length range (eg
`"abcdef"[4..3]`) is confusing: it gives the condition that failed to hold,
whilst all the other panic messages give the condition that did hold.
Before:
begin <= end (4 <= 3) when slicing `abcdef`
After:
begin > end (4 > 3) when slicing `abcdef`
Replace `self.end() == usize::MAX` and `self.end() + 1 > slice.len()`
with `self.end() >= slice.len()`. Same reasoning as previous commit.
Also consolidate the str panicking functions into function.
Clean up query macros for `cache_on_disk_if`
This PR aims to make the macros for dealing with `cache_on_disk_if` a bit easier to read and work with.
There should be no change to compiler behaviour.
The checks for `self.end() == usize::MAX` and `self.end() + 1 > slice.len()`
can be replaced with `self.end() >= slice.len()`, since
`self.end() < slice.len()` implies both
`self.end() <= slice.len()` and
`self.end() < usize::MAX`.
Add a `codegen-llvm` test to check the number of `icmp` instrucitons
generated for each `SliceIndex` method on the various range types. This
will be updated in the next commit when `SliceIndex::get` is optimized
for `RangeInclusive`.
This essentially folds the call to `region_from_element` into `RegionInferenceContext`,
and simplifies the error variant for this case. It also clarifies the type
information on the methods called to emphasise the fact that they only ever use
placeholder regions in the diagnostics, and completely ignore any other element.
aliases may be rigid even if they don't reference params. If the alias isn't well-formed, trying to normalize it as part of the input should have already failed
Handle race when coloring nodes concurrently as both green and red
This fixes a race where a duplicate dep node gets written to the dep graph if a node was marked as green and promoted during execution, then marked as red after execution.
This can occur when a `no_hash` query A depends on a query B which cannot be forced so it was not colored when starting execution of query A. During the execution of query A it will execute query B and color it green. Before A finishes another thread tries to mark A green, this time succeeding as B is now green, and A gets promoted and written to metadata. Execution of A then finishes and because it's `no_hash` we assume the result changed and thus we color the node again, now as red and write it to metadata again. This doesn't happen with non-`no_hash` queries as they will be green if all their dependencies are green.
This changes the code coloring nodes red to also use `compare_exchange` to deal with this race ensuring that the coloring of nodes only happens once.
Fixesrust-lang/rust#150018Fixesrust-lang/rust#142778Fixesrust-lang/rust#141540
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#152364 (Port a lot of attributes to the new parser)
- rust-lang/rust#151954 (Add help message suggesting explicit reference cast for From/TryFrom)
- rust-lang/rust#152148 (Move `impl Interner for TyCtxt` to its own submodule)
- rust-lang/rust#152226 (Modernize diagnostic for indeterminate trait object lifetime bounds)
- rust-lang/rust#152351 (Remove `SubdiagMessage` in favour of the identical `DiagMessage`)
- rust-lang/rust#152417 (Move the needs-drop check for `arena_cache` queries out of macro code)
- rust-lang/rust#150688 (typeck: Make it clearer that `check_pat_lit` only handles literal patterns)
- rust-lang/rust#152293 (Format heterogeneous try blocks)
- rust-lang/rust#152355 (Update documentation of rustc_macros)
- rust-lang/rust#152396 (Uplift `Predicate::allow_normalization` to `rustc_type_ir`)
Format heterogeneous try blocks
The tracking issue for `try_blocks_heterogeneous` is https://github.com/rust-lang/rust/issues/149488.
This follows the formatting of homogeneous try blocks (feature `try_blocks`) by considering `try bikeshed <type>` to be the equivalent of `try` (in particular a single "token").
An alternative would be to permit breaking between `bikeshed` and `<type>`, but given that those 2 elements are an explicitly temporary part of the syntax, it doesn't seem worth it. There also doesn't seem to be any existing precedent breaking between a keyword and a type. It also doesn't seem to be useful in practice, given that the type itself doesn't break (which is how it works for the return type of closures) and has more chances to dominate the length in case a break is necessary.
Happy to adapt anything in case this formatting is not optimal.
The test is also copied from homogeneous try blocks with 2 additional test cases to demonstrate the behavior with long types.
See [#t-lang > try blocks @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/try.20blocks/near/572387493) for context.
typeck: Make it clearer that `check_pat_lit` only handles literal patterns
Nowadays, the `hir::PatExprKind` enum guarantees that “expressions” in patterns can only be paths or literals.
`PatExprKind::Path` is already handled by the previous match arm, so we can make this match arm explicitly match on `PatExprKind::Lit` without losing exhaustiveness.
There should be no actual change to compiler behaviour.
Remove `SubdiagMessage` in favour of the identical `DiagMessage`
For https://github.com/rust-lang/rust/issues/151366
Just some more cleanup :)
SubdiagMessage is now identical to DiagMessage, so there's no point in having both of them
Move the needs-drop check for `arena_cache` queries out of macro code
This is slightly simpler than before, because now the macro only needs to call a single function, and can just unconditionally supply `tcx` and a typed arena.
There should be no actual change to compiler behaviour.
Remove `SubdiagMessage` in favour of the identical `DiagMessage`
For https://github.com/rust-lang/rust/issues/151366
Just some more cleanup :)
SubdiagMessage is now identical to DiagMessage, so there's no point in having both of them
Modernize diagnostic for indeterminate trait object lifetime bounds
* remove suggestion from the diagnostic message (bad style, too long) and turn it into a structured suggestion
* replace *object type* with *trait object type* since the former is an outdated term
Move `impl Interner for TyCtxt` to its own submodule
This impl is several hundred lines of mostly self-contained, mostly boilerplate code that can be extracted out of the dauntingly large `rustc_middle::ty::context` module.
- The trait and its impl were introduced by https://github.com/rust-lang/rust/pull/97287.
---
There should be no change to compiler behaviour.
Add help message suggesting explicit reference cast for From/TryFrom
Closesrust-lang/rust#109829
Improves E0277 diagnostics when a `From` or `TryFrom` implementation is expected, but the provided type is a reference that can be explicitly cast to a type the trait can convert from.
Unit struct constructors used as the RHS of a `type const` associated
const used to ICE during normalization because they were lowered as
`Const::new_unevaluated` with a Ctor def_id. The compiler now properly
constructs a concrete ValTree value for const constructors.
The latter is a new module.
As well as the code motion, some other changes were required.
- `QueryJobId` methods became free functions so they could move while
`QueryJobId` itself stayed put. This was so `QueryMap` and
`QueryJobInfo` could be moved.
- Some visibilities in `rustc_query_system` required changing.
- `collect_active_jobs_from_all_queries` is no longer required in `trait
QueryContext`.
Requiring `fn` in the macro syntax makes it a little more obvious that the
macro declares functions with those names, and makes them easier to grep for.
Remove the compiler adhoc group
Since triagebot now allows configuring rotation mode through a specific team.
Original review rotation:
```toml
compiler = [
"@BoxyUwU",
"@chenyukang",
"@davidtwco",
"@eholk",
"@fee1-dead",
"@fmease",
"@jackh726",
"@jieyouxu",
"@jdonszelmann",
"@JonathanBrouwer",
"@madsmtm",
"@mati865",
"@Nadrieril",
"@nnethercote",
"@oli-obk",
"@petrochenkov",
"@SparrowLii",
"@TaKO8Ki",
"@tiif",
"@WaffleLapkin",
"@wesleywiser",
]
```
I went through all the remaining members of t-compiler now and set their `compiler` team rotation to be off, to match the original state. You can check it with `team-stats compiler`.
r? @davidtwco
Update to Xcode 26.2
Update our CI to run with Xcode 26.
This means that:
- LLVM will be built with a newer Clang version (before Apple Clang 15, now Apple Clang 17).
- Our binaries (e.g. `rustc` and `libstd*.dylib`) will have their SDK version raised (before macOS 14.5, now 26.2).
- Our binaries will be built with a newer linker (before 1053.12, now 1230.1).
The last two points can be observed with:
```sh
$ vtool -show-build ./build/host/stage1/bin/rustc
Load command 10
cmd LC_BUILD_VERSION
cmdsize 32
platform MACOS
minos 11.0
sdk 26.2
ntools 1
tool LD
version 1230.1
$ vtool -show-build ./build/host/stage1/lib/rustlib/aarch64-apple-darwin/lib/libstd*.dylib
Load command 9
cmd LC_BUILD_VERSION
cmdsize 32
platform MACOS
minos 11.0
sdk 26.2
ntools 1
tool LD
version 1230.1
```
This shouldn't have much of an effect, but things like `dyld` is known to inspect the SDK version, so it _might_ expose some latent bugs (I really don't expect it to though).
This also updates the macOS runners to run on macOS 15 (the macOS 14 runners only have up to Xcode 16.2 available). That is desirable anyhow, as [the macOS 14 runners will be deprecated in July](https://github.com/actions/runner-images/issues/13518). This is probably also required for https://github.com/rust-lang/rust/pull/147192.
r? shepmaster
Add `s390x-unknown-none-softfloat` with `RustcAbi::Softfloat`
followup on rust-lang/rust#150766
add an `s390x-unknown-none-softfloat` target to use for kernel compilation, as the Linux kernel does not wish to pay the overhead of saving float registers by default on kernel switch. this target's `extern "C"` ABI is unspecified, so it is unstable and subject to change between versions, just like the Linux intrakernel ABI and `extern "Rust"` ABIs are unstable.
enforce target feature incompatibility by adding `RustcAbi::Softfloat`. this is itself just a rename of `RustcAbi::X86Softfloat`, accepting both "x86-softfloat" and "softfloat" as valid strings in the target.json format. the target-features of `"soft-float"` and `"vector"` are incompatible for s390x, so issue a compatibility warning if they are combined.
rustc_parse_format: improve diagnostics for unsupported debug = syntax
Detect Python-style f-string debug syntax in format strings and emit a
clear diagnostic explaining that it is not supported in Rust. When the
intended operation can be inferred, suggest the corresponding Rust
alternative (e.g. `dbg!` for `{x=}`).
Update mgca to use `type const` syntax instead of the `#[type_const]` attribute.
This PR changes the `#[type_const]` attribute to the `type const` syntax for https://github.com/rust-lang/rust/issues/132980.
This will fixes https://github.com/rust-lang/rust/issues/151273 and similar issues, since we need to check `type const` of items before expansion. The move to add a syntax was mentioned here: https://github.com/rust-lang/rust/pull/151289#issuecomment-3765241397
The first part of this PR adds support by allowing `type const <IDENT>: <TYPE> { = <EXPR> };` syntax in `rustc_parse/src/parser/item.rs`.
The next part since the AST item does not contain enough information to determine if we have a `type const` was rework `ConstItemRhs` into `ConstItemRhsKind` to store the information since we no longer have the attribute acting as a source of extra data/metadata.
The hir node `ConstItemRhsKind` current shape mostly works, except in the case of `TraitItemKind` where it is an option. I initially went about giving `hir::ConstItemRhsKind` a similar form the AST, but it touches a lot more lines of code and files so because of that, the less invasive option was to add a simple boolean flag to `TraitItemKind`.
The forth part of this PR includes adding a query I called `is_rhs_type_const` so that we can handle both local and foreign def_ids.
The fifth aspect of the PR is adding a `mgca_type_const_syntax` feature gate that is checked before expansion. The standard mgca feature gate is ran after expansion. This feature gate allows for conditional compilation (e.g #[cfg(..)]) of the `type const` syntax in nightly without `min_generic_const_args` being enabled.
The last bit is updating all the the tests that used the `#[type_const]` attribute to use the new syntax that failed because of the changes. This is the bulk of touched/edited files in the PR.
r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args
Upstream has improved InstCombine so that it can shrink added constants
using known zeroes, which caused a little bit of change in this test. As
far as I can tell either output is fine, so we just accept both.
This noop PR makes the new comma-removing lint PR less noisy, allowing
it focus only on the new functionality
See rust-lang/rust-clippy#16530
changelog: none
Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash`
`JobOwner` appears to have had more responsibilities in the past, but nowadays it's just a stack-guard object used by `execute_job` to poison the query state for the current key if some inner part of query execution panics.
The new name and comments should hopefully be clearer about its (limited) role.
I have also included a follow-up change that stores both the key and its previously-computed hash in the guard, instead of just the key. This avoids having to pass the key to `complete`, and avoids having to recompute the hash in `drop`.
r? nnethercote (or compiler)
Check stalled coroutine obligations eagerly
Fixesrust-lang/rust#151322Fixesrust-lang/rust#151323Fixesrust-lang/rust#137916Fixesrust-lang/rust#138274
The problem is that stalled coroutine obligations can't be satisifed so that they cause normalization to fail in `mir_borrowck`.
Thus, we failed to register any opaque to storage in the next solver.
I fix it by checking these obligations earlier in `mir_borrowck`.
r? @lcnr
std: introduce path normalize methods at top of `std::path`
Closesrust-lang/rust#142931
Mention other methods that call `conponents` and `canonicalize` that fully normalize path. And fix two typo.
r? libs
Fix an ICE in the vtable iteration for a trait reference in const eval when a supertrait not implemented
compiler/rustc_trait_selection/src/traits/vtable.rs@`vtable_entries`:
The impossible predicates check in `vtable_entries` used `instantiate_own` which only includes the method's own `where` clauses, without the parent trait's bounds. Replace it with `instantiate_and_check_impossible_predicates` which also checks the trait ref itself, so unsatisfied supertrait bounds are caught and the method is marked `Vacant` instead of ICEing.
Closesrust-lang/rust#137190.
Closesrust-lang/rust#135470.
Set crt_static_allow_dylibs to true for Emscripten target
And add a test. This is followup work to rust-lang/rust#151704. It introduced a regression where cargo is now unwilling to build cdylibs for Emscripten because `crt_static_default` is `true` but `crt_static_allows_dylibs` is `false`. Unfortunately the added test does not fail without the change because the validation logic is in Cargo, not in rustc. But it's good to have some coverage of this anyways.
Align `ArrayWindows` trait impls with `Windows`
With `slice::ArrayWindows` getting ready to stabilize in 1.94, I noticed that it currently has some differences in trait implementations compared to `slice::Windows`, and I think we should align these.
- Remove `derive(Copy)` -- we generally don't want `Copy` for iterators at all, as this is seen as a footgun (e.g. rust-lang/rust#21809). This is obviously a breaking change though, so we should only remove this if we also backport the removal before it's stable. Otherwise, it should at least be replaced by a manual impl without requiring `T: Copy`.
- Manually `impl Clone`, simply to avoid requiring `T: Clone`.
- `impl FusedIterator`, because it is trivially so. The `since = "1.94.0"` assumes we'll backport this, otherwise we should change that to the "current" placeholder.
- `impl TrustedLen`, because we can trust our implementation.
- `impl TrustedRandomAccess`, because the required `__iterator_get_unchecked` method is straightforward.
r? libs-api
@rustbot label beta-nominated
(at least for the `Copy` removal, but we could be more selective about the rest).
Revert, but without type const.
Update symbol for feature err, then update suggestion output, and lastly update tests that change because of those.
Update these new tests with the correct syntax, and few existing tests with the new outputs the merge with main added.
Fix for tidyfmt and some errors when manually resolving a merge conflicts.
Update these tests to use update error messages and type const syntax.
Update comments and error message to use new syntax instead of old type_const attribute.
Remove the type_const attribute
update some more tests to use the new syntax.
Update these test cases.
update feature gate test
Change gate logic for `mgca_type_const_syntax` to work also if `min_generic_const_args` is enabled.
Create a new feature gate that checks for the feature before expansion.
Make rustfmt handle the `type const` syntax correctly.
Add a convience method to check if a RhsKind is type const.
Rename `Const` discriminant to `Body` for `ConstItemRhsKind`
Give the `TraitItemKind` flag an enum instead of a simple bool to better describe what the flag is for.
Update formatting for these match statements.
Update clippy test to use type const syntax.
Update test to use type const syntax.
update rustfmt to match ast items.
Update clippy to match ast and hir items.
Few more test cases that used old attribute, instead of 'type const'
Update to match the output from the feature gate checks.
tidyfmt adjustments.
Update the is_type_const, so I can constrain record!(..) in encoder.rs
Update conditional compilation test.
Move the feature gate to after expansion to allow for cfg(...) to work.
Update some more tests to use the new syntax.
Update type const tests in associated-const-bindings to use new syntax.
Don't check based off the attribute, but the item here.
Update some tests outside of the const_generics folder that were using #[type_const]
update the tests in associated consts that use #[type_const] to use type const
Update these mgca tests with the type const syntax.
Add a flag to TraitItemKind for detecting type const for now. Maybe later change ItemConstRhs to have optional consts but that touches a lot more lines of code.
Don't need into for these now that it's a query.
Add is_type_const query to handle foreign def ids.
update this test to use type const syntax.
Fix logic here, we only want to lower if there is expression in this case.
Update built-in macros to use ConstItemRhsKind
Update more instance of the old ConstItemRhs.
Rename ConstItemKind to ConstItemRhsKind, I noticed there is a typed called ConstantItemKind, so add the Rhs to the name to avoid confusion.
Update lower to use ConstItemKind
Add an other helper method to check if the rhs kinda has an expr.
Update item parse to use ConstItemKind enum.
Felt the field name could a be little clear when editing a few other things.
Change the ConstItem struct see know if we have a type const or regular const.
Make sure this syntax is properly feature gated.
Revert, but without type const.
Update symbol for feature err, then update suggestion output, and lastly update tests that change because of those.
Update these new tests with the correct syntax, and few existing tests with the new outputs the merge with main added.
Fix for tidyfmt and some errors when manually resolving a merge conflicts.
Update these tests to use update error messages and type const syntax.
Update comments and error message to use new syntax instead of old type_const attribute.
Remove the type_const attribute
update some more tests to use the new syntax.
Update these test cases.
update feature gate test
Change gate logic for `mgca_type_const_syntax` to work also if `min_generic_const_args` is enabled.
Create a new feature gate that checks for the feature before expansion.
Make rustfmt handle the `type const` syntax correctly.
Add a convience method to check if a RhsKind is type const.
Rename `Const` discriminant to `Body` for `ConstItemRhsKind`
Give the `TraitItemKind` flag an enum instead of a simple bool to better describe what the flag is for.
Update formatting for these match statements.
Update clippy test to use type const syntax.
Update test to use type const syntax.
update rustfmt to match ast items.
Update clippy to match ast and hir items.
Few more test cases that used old attribute, instead of 'type const'
Update to match the output from the feature gate checks.
tidyfmt adjustments.
Update the is_type_const, so I can constrain record!(..) in encoder.rs
Update conditional compilation test.
Move the feature gate to after expansion to allow for cfg(...) to work.
Update some more tests to use the new syntax.
Update type const tests in associated-const-bindings to use new syntax.
Don't check based off the attribute, but the item here.
Update some tests outside of the const_generics folder that were using #[type_const]
update the tests in associated consts that use #[type_const] to use type const
Update these mgca tests with the type const syntax.
Add a flag to TraitItemKind for detecting type const for now. Maybe later change ItemConstRhs to have optional consts but that touches a lot more lines of code.
Don't need into for these now that it's a query.
Add is_type_const query to handle foreign def ids.
update this test to use type const syntax.
Fix logic here, we only want to lower if there is expression in this case.
Update built-in macros to use ConstItemRhsKind
Update more instance of the old ConstItemRhs.
Rename ConstItemKind to ConstItemRhsKind, I noticed there is a typed called ConstantItemKind, so add the Rhs to the name to avoid confusion.
Update lower to use ConstItemKind
Add an other helper method to check if the rhs kinda has an expr.
Update item parse to use ConstItemKind enum.
Felt the field name could a be little clear when editing a few other things.
Change the ConstItem struct see know if we have a type const or regular const.
Make sure this syntax is properly feature gated.
Currently clippy is run in CI as part of the macOS build. This is a
little confusing, because clippy failures just show as
"Rust (macos-latest)" which make it look like a macOS build failure.
Instead, treat clippy as a separate build step, like miri and rustfmt.
This should also make CI a little faster, because it reduces macOS
runner usage (which tend to be slower than Linux on GitHub actions),
and it reduces the number of steps where we need to install clippy.
This value is a previously-computed hash of the key, so it makes sense to
bundle it with the key inside the guard, since the guard will need it on
completion anyway.
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#152357 (std: Don't panic when removing a nonexistent UEFI var)
- rust-lang/rust#152180 (Port `rustc_reservation_impl` to the new attribute parser)
- rust-lang/rust#152276 (Add message format checking)
The tests were using `rug::ln_gamma` as a reference for `libm::lgamma`,
which actually computes the natural logarithm *of the absolute value* of
the Gamma function.
This changes the range of inputs used for the icount-benchmarks of these
functions, which causes false regressions in [1].
[1]: https://github.com/rust-lang/compiler-builtins/actions/runs/21788698368/job/62864230903?pr=1075#step:7:2710.
Fixes: a1a066611dc2 ("Create interfaces for testing against MPFR")
Add message format checking
Checks the indentation of diagnostic messages, it checks that everything is at least as indented as the attribute that contains it
r? @jdonszelmann (Anyone else, also feel free to review, just assigning to Jana because she's been reviewing the other PRs)
std: Don't panic when removing a nonexistent UEFI var
`std::env::remove_var` does not say that deleting a nonexistent variable is an error (and at least on Linux, it indeed does not cause an error).
The UEFI Shell Protocol spec also doesn't say it's an error, but the edk2 implementation delegates to the UEFI runtime `SetVariable` function, which returns `EFI_NOT_FOUND` when trying to delete a nonexistent variable.
Change the UEFI implementation to check for a `NotFound` error and treat it as success.
CC @Ayush1325
Remove `QueryDispatcher`
`QueryDispatcher` is a trait that existed purely because `rustc_query_system` had code that didn't have access to `TyCtxt`. That is no longer the case, so the trait can be removed.
r? @Zalathar
It existed only to bridge the divide between `rustc_query_system` and
`rustc_query_impl`. But enough pieces have been moved from the former to
the latter that the trait is no longer needed. Less indirection and
abstraction makes the code easier to understand.
It takes an `is_anon` argument, but it's now generic over `QueryFlags`,
which contains the same `is_anon` field. So the argument is no longer
necessary.
tests will check:
- correct emit of assembly for softfloat target
- incompatible set features will emit warnings/errors
- incompatible target tripples in crates will not link
This target is intended to be used for kernel development. Becasue on s390x
float and vector registers overlap we have to disable the vector extension.
The default s390x-unknown-gnu-linux target will not allow use of
softfloat.
Co-authored-by: Jubilee <workingjubilee@gmail.com>
Port `rustc_insignificant_dtor`
r? @JonathanBrouwer
Second commit removes it from an impl in std. I looked, and I really think it had no effect in the past. We only look for this attr on ADTs...
Implement MVP for opaque generic const arguments
This is meant to be the interim successor to generic const expressions.
Essentially, const item RHS's will be allowed to do arbitrary const
operations using generics. The limitation is that these const items will
be treated opaquely, like ADTs in nominal typing, such that uses of them
will only be equal if the same const item is referenced. In other words,
two const items with the exact same RHS will not be considered equal.
I also added some logic to check feature gates that depend on others
being enabled (like oGCA depending on mGCA).
### Coherence
During coherence, OGCA consts should be normalized ambiguously because
they are opaque but eventually resolved to a real value. We don't want
two OGCAs that have the same value to be treated as distinct for
coherence purposes. (Just like opaque types.)
This actually doesn't work yet because there are pre-existing
fundamental issues with equate relations involving consts that need to
be normalized. The problem is that we normalize only one layer of the
const item and don't actually process the resulting anon const. Normally
the created inference variable should be handled, which in this case
would cause us to hit the anon const, but that's not happening.
Specifically, `visit_const` on `Generalizer` should be updated to be
similar to `visit_ty`.
r? @BoxyUwU
In `report_sub_sup_conflict`, when calling `values_str` for
`sub_trace.values`, the code was incorrectly passing `sup_trace.cause`
instead of `sub_trace.cause`. This is a copy-paste error from the
preceding line which correctly uses `sup_trace.cause` for
`sup_trace.values`.
The `cause` parameter matters for `ValuePairs::PolySigs` comparisons,
where `values_str` inspects `cause.code()` to extract
`impl_item_def_id` and `trait_item_def_id` for richer function
signature diagnostics. Using the wrong trace's cause could produce
incorrect function def IDs, leading to misleading diagnostic output
when the sub and sup traces originate from different obligations.
Even for non-PolySigs variants where `cause` is currently unused by
`values_str`, passing the semantically correct cause is the right
thing to do for correctness and maintainability.
Make format-like macro calls look similar to what `cargo fmt` does automatically - remove trailing commas. When removing a comma, I also inlined some variables for consistency and clarity.
Streamline `rustc_span::HashStableContext`.
Currently this trait has five methods. But it only really needs three.
For example, currently stable hashing of spans is implemented in `rustc_span`, except a couple of sub-operations are delegated to `rustc_query_system`: `def_span` and `span_data_to_lines_and_cols`. These two delegated sub-operations can be reduced to a single delegated operation that does the full hash computation.
Likewise, `assert_default_hashing_controls` depends on two delegated sub-operations, `hashing_controls` and
`unstable_opts_incremental_ignore_spans`, and can be simplified.
I find the resulting code simpler and clearer -- when necessary, we do a whole operation in `rustc_query_system` instead of doing it partly in `rustc_span` and partly in `rustc_query_system`.
r? @cjgillot
It's always `SemiDynamicQueryDispatcher`, so we can just use that type
directly. (This requires adding some explicit generic params to
`QueryDispatcherUnerased`.) Less indirection makes the code clearer, and
this is a prerequisite for the next commit, which is a much bigger
simplification.
Query keys must be stably hashable. Currently this requirement is
expressed as a where-clause on `impl QueryDispatcher for
SemiDynamicQueryDispatcher` and a where-clause on
`create_deferred_query_stack_frame`.
This commit removes those where-clause bounds and adds a single bound to
`QueryCache::Key`, which already has some other bounds. I.e. it
consolidates the bounds. It also gives them a name (`QueryCacheKey`) to
avoid repeating them. There is also a related `Key` trait in
`rustc_middle`; it should probably be merged with `QueryCacheKey` in the
future, but not today.
This cleanup helps with the next two commits, which do bigger
rearrangements, and where the where-clauses caused me some difficulties.
Stop having two different alignment constants
Now that there's a `<T as SizedTypeProperties>::ALIGNMENT` constant, `Alignment::of` can use that instead of an inline constant, like how `Layout::new` uses the constant from `SizedTypeProperties`.
Reword the caveats on `array::map`
Thanks to #107634 and some improvements in LLVM (particularly [`dead_on_unwind`](https://llvm.org/docs/LangRef.html#parameter-attributes)), the method actually optimizes reasonably well now.
So focus the discussion on the fundamental ordering differences where the optimizer might never be able to fix it because of the different behaviour, and keep encouraging `Iterator::map` where an array wasn't actually ever needed.
bootstrap: always propagate `CARGO_TARGET_{host}_LINKER`
We were already setting `CARGO_TARGET_{target}_LINKER` when there is a
setting in `bootstrap.toml`, and when the host and target are the same,
this is also used for build scripts and proc-macros.
However, the host value wasn't set when building for any other target,
and Cargo would see that as a fingerprint change for those build
artifacts, rebuilding them.
If we always set the `CARGO_TARGET_{host}_LINKER`, then those build
scripts will keep a consistent Cargo fingerprint, so they'll remain
cached no matter how we're alternating targets.
diagnostics: fix ICE in closure signature mismatch
Fixesrust-lang/rust#152331
Fixes an ICE where `AdjustSignatureBorrow` caused a panic because it attempted to set the `len` argument which was already defined by the parent diagnostic.
Both variants used `len` as argument name, but can both be present in a diagnostic. They now use different names for the argument.
Cleanup offload datatransfer
There are 3 steps to run code on a GPU: Copy data from the host to the device, launch the kernel, and move it back.
At the moment, we have a single variable describing the memory handling to do in each step, but that makes it hard for LLVM's opt pass to understand what's going on. We therefore split it into three variables, each only including the bits relevant for the corresponding stage.
cc @jdoerfert @kevinsala
r? compiler
Fix a few diagnostics
When working on the inline diagnostics conversion (https://github.com/rust-lang/rust/issues/151366), I noticed that my script sometimes took the wrong message.
Because it didn't happen very often, I just fixed it manually when a uitest fails.
However I got paranoid that the script changed messages that were not covered by uitests, so I checked for all messages in the previous `messages.ftl` files, whether they occured at least once in the codebase. I found 3 messages that indeed were wrongly replaced by my script, fixed them, and added uitests to make sure this doesn't happen again :)
r? @jdonszelmann (Anyone else, also feel free to review, just assigning to Jana because she's been reviewing the other PRs)
Replace some `feature(core_intrinsics)` with stable hints
I noticed that some compiler crates use `feature(core_intrinsics)` for optimization hints, when they could potentially be using stable `std::hint` functions instead.
This PR replaces the occurrences in `rustc_arena` and `rustc_data_structures`.
Fix `SourceFile::normalized_byte_pos`
This method was broken by 258ace6, which changed `self.normalized_pos` to use relative offsets however this method continued to compare against an absolute offset.
Also adds a regression test for the issue that this method was originally introduced to fix.
Closesrust-lang/rust#149568
Fixes regression of rust-lang/rust#110885
r? cjgillot (as author of the breaking commit)
This is meant to be the interim successor to generic const expressions.
Essentially, const item RHS's will be allowed to do arbitrary const
operations using generics. The limitation is that these const items will
be treated opaquely, like ADTs in nominal typing, such that uses of them
will only be equal if the same const item is referenced. In other words,
two const items with the exact same RHS will not be considered equal.
I also added some logic to check feature gates that depend on others
being enabled (like oGCA depending on mGCA).
= Coherence =
During coherence, OGCA consts should be normalized ambiguously because
they are opaque but eventually resolved to a real value. We don't want
two OGCAs that have the same value to be treated as distinct for
coherence purposes. (Just like opaque types.)
This actually doesn't work yet because there are pre-existing
fundamental issues with equate relations involving consts that need to
be normalized. The problem is that we normalize only one layer of the
const item and don't actually process the resulting anon const. Normally
the created inference variable should be handled, which in this case
would cause us to hit the anon const, but that's not happening.
Specifically, `visit_const` on `Generalizer` should be updated to be
similar to `visit_ty`.
`std::env::remove_var` does not say that deleting a nonexistent variable
is an error (and at least on Linux, it indeed does not cause an
error).
The UEFI Shell Protocol spec also doesn't say it's an error, but the
edk2 implementation delegates to the UEFI runtime `SetVariable`
function, which returns `EFI_NOT_FOUND` when trying to delete a
nonexistent variable.
Change the UEFI implementation to check for a `NotFound` error and treat
it as success.
Start cutting down `rustc_query_system`
The query system is implemented in `rustc_query_system`, `rustc_middle`, and `rustc_query_impl`. `rustc_query_system` is hamstrung by not having access to `TyCtxt`, and there seems to be consensus to eliminate it. It's contents can be moved into the other two crates. Moving as much stuff as possible to `rustc_query_impl` is preferred, because `rustc_middle` is already so big.
This PR starts this process. It moves one small function to `rustc_middle` and a good chunk of code to `rustc_query_impl`.
Once `rustc_query_system` is gone (or at least shrunk down a lot more) some of the traits like `DepContext`, `QueryContext`, and `QueryDispatcher` will be removable.
r? @Zalathar
Currently this trait has five methods. But it only really needs three.
For example, currently stable hashing of spans is implemented in
`rustc_span`, except a couple of sub-operations are delegated to
`rustc_query_system`: `def_span` and `span_data_to_lines_and_cols`.
These two delegated sub-operations can be reduced to a single delegated
operation that does the full hash computation.
Likewise, `assert_default_hashing_controls` depends on two delegated
sub-operations, `hashing_controls` and
`unstable_opts_incremental_ignore_spans`, and can be simplified.
I find the resulting code simpler and clearer -- when necessary, we do a
whole operation in `rustc_query_system` instead of doing it partly in
`rustc_span` and partly in `rustc_query_system`.
The previous commit moved some code from `rustc_query_system`, which
doesn't have access to `TyCtxt` and `QueryCtxt`, to `rustc_query_impl`,
which does. We can now remove quite a bit of indirection.
- Three methods in `trait QueryContext` are no longer needed
(`next_job_id`, `current_query_job`, `start_query`). As a result,
`QueryCtxt`'s trait impls of these methods are changed to inherent
methods.
- `qcx: Q::Qcx` parameters are simplified to `qcx: QueryCtxt<'tcx>`.
- `*qcx.dep_context()` occurrences are simplified to `qcx.tcx`, and
things like `qcx.dep_context().profiler()` become `qcx.tcx.prof`.
- `DepGraphData<<Q::Qcx as HasDepContext>::Deps>` becomes
`DepGraphData<DepsType>`.
In short, various layers of indirection and abstraction are cut away.
The resulting code is simpler, more concrete, and easier to understand.
It's a good demonstration of the benefits of eliminating
`rustc_query_system`, and there will be more to come.
[Note: this commit conceptually moves 75% of a file to another location,
and leaves 25% of it behind. It's impossible to preserve all the git
history. To preserve git history of the moved 75%, in this commit we
rename the file and remove the 25% from it, leaving the code in an
incomplete (uncompilable) state. In the next commit we add back the
25% in the old location.]
We are in the process of eliminating `rustc_query_system`. Chunks of it
are unused by `rustc_middle`, and so can be moved into
`rustc_query_impl`. This commit does some of that.
Mostly it's just moving code from one file to a new file. There are a
couple of non-trivial changes.
- `QueryState` and `ActiveKeyStatus` must remain in `rustc_query_system`
because they are used by `rustc_middle`. But their inherent methods
are not used by `rustc_middle`. So these methods are moved and
converted to free functions.
- The visibility of some things must increase. This includes `DepGraphData`
and some of its methods, which are now used in `rustc_query_impl`.
This is a bit annoying but seems hard to avoid.
What little is left behind in
`compiler/rustc_query_system/src/query/plumbing.rs` will be able to
moved into `rustc_query_impl` or `rustc_middle` in the future.
Weaken `assert_dep_node_not_yet_allocated_in_current_session` for multiple threads
This changes `assert_dep_node_not_yet_allocated_in_current_session` to not panic if the node is already marked green. Another thread may manage to mark it green if there was uncolored node when we initially tried to mark it green.
Suppress unused_mut lint if mutation fails due to borrowck error
Remedying the borrowck error will likely result in the mut becoming used, and therefore the lint is likely incorrect.
Fixesrust-lang/rust#152024
r? compiler
Remove some unnecessary `try`-related type annotations
I left a few, like
```rust
let result: Result<_, ModError<'_>> = try {
```
where it felt like seeing it might still be useful for the reader.
Feel free to push back on any of these changes if you think they should be left alone.
Support long diff conflict markers
git can be configured to use more than 7 characters for conflict markers, and jj automatically uses longer conflict markers when the text contains any char sequence that could be confused with conflict markers. Ensure that we only point at markers that are consistent with the start marker's length.
Ensure that we only consider char sequences at the beginning of a line as a diff marker.
Fix https://github.com/rust-lang/rust/issues/150352.
GVN: Only propagate borrows from SSA locals
Fixes https://github.com/rust-lang/rust/issues/141313. This is a more principled fix than https://github.com/rust-lang/rust/pull/147886.
Using a reference that is not a borrowing of an SSA local at a new location may be UB.
The PR has two major changes.
The first one, when introducing a new dereference at a new location, is that the reference must point to an SSA local or be an immutable argument. `dereference_address` has handled SSA locals.
The second one, if we cannot guard to the reference point to an SSA local in `visit_assign`, we have to rewrite the value to opaque. This avoids unifying the following dereferences that also are references:
```rust
let b: &T = *a;
// ... `a` is allowed to be modified. `c` and `b` have different borrowing lifetime.
// Unifying them will extend the lifetime of `b`.
let c: &T = *a;
```
See also https://github.com/rust-lang/rust/issues/130853.
This still allows unifying non-reference dereferences:
```rust
let a: &T = ...;
let b: T = *a;
// ... a is NOT allowed to be modified.
let c: T = *a;
```
r? @cjgillot
Avoid a bogus THIR span for `let x = offset_of!(..)`
The code that creates spans for THIR `let` statements was doing span endpoint manipulation without checking for inclusion/context, resulting in bogus spans observed in https://github.com/rust-lang/rust/pull/151693.
The incorrect spans are easiest to observe with `-Zunpretty=thir-tree`, but they also cause strange user-facing diagnostics for irrefutable let-else.
Remove `rustdoc` adhoc group
With https://github.com/rust-lang/triagebot/pull/2273, reviewers can now tell triagebot to opt them out of being assigned through a given team, so that `r? <team>` does not consider them if they don't want to.
That means that we can now finally get rid of adhoc groups that correspond to actual Rust teams. I wanted to start with a smaller team than `t-compiler` to test this, so I started with `rustdoc`, which was the smallest team that I found an adhoc group for.
Currently, the `rustdoc` team contains the following members:
- aDotInTheVoid
- GuillaumeGomez
- notriddle
- fmease
- camelid
- Manishearth
- Urgau
- lolbinarycat
- yotamofek
Only three of those were previously assignable through `r? rustdoc`. So to reproduce the previous state, I will run `as <username> work set-team-rotation-mode rustdoc off` for the remaining members of the `rustdoc` team before this is merged.
If more people from `t-rustdoc` want to join the review rotation, they can send [triagebot](https://rust-lang.zulipchat.com/#narrow/dm/261224-triagebot) a DM with `work set-team-rotation-mode rustdoc on`.
CC @rust-lang/rustdoc
Introduce helper `ty::Generics::has_own_self`
The pattern `generics.has_self && generics.parent.is_none()` only occurs 5 times in rustc+rustdoc at the time of writing but I keep getting reminded/annoyed that there doesn't exist a nice wrapper fn that abstracts it & immediately clarifies the intent. Most recently that happened when working on my open PR RUST-129543 in which I add yet another occurrence of it ([via](ae8c0a5a46/compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs (L1771-L1773))).
For context, `generics.has_self` indicates that there is a `Self` type parameter (at position 0) in the "oldest" / "root" generic parameter list in the chain of generic parameter lists (rephrased: it's true if the chain *as a whole* has a `Self` type parameter). `has_own_self` on the other hand indicates that the `own_params` contain a `Self` type parameter which is sometimes needed for offsetting the own parameters or arguments.
RwLock: refine documentation to emphasize non-reentrancy guarantees
This addresses the need for clarification brought up in rust-lang/rust#149693. Specifically, it notes that some implementations may choose to panic if they detect deadlock situations during recursive locking attempts for both `read()` and `write()` calls.
* Provide an example highlighting that multiple read locks can be held across different threads simultaneously.
* Remove the example that shows a situation that can potentially deadlock. (as demonstrated in the very same documentation a few paragraphs above)
* Improve documentation regarding the possibility of panics during recursive read or write lock attempts.
Issues: https://github.com/rust-lang/rust/issues/149693
Convert to inline diagnostics in `rustc_lint`
For https://github.com/rust-lang/rust/issues/151366
r? @jdonszelmann
This was a big one! Second to last one, `rustc_parse` is the last one and even bigger :P
Also duplicate `#[expect]` attribute in `#[derive]`-ed code
This PR updates our derive logic to also duplicate any `#[expect]` attribute in the `#[derive]`-ed code, as we already do for all the other lint attribute (`#[allow]`, `#[warn]`, `#[deny]`, ...).
The original and duplicated attribute share the same attribute id, which due to the way [`check_expectations`](56aaf58ec0/compiler/rustc_lint/src/expect.rs (L28-L46)) is implemented makes the expectation fulfilled if the lint is either trigger in the original code or the derived code.
This was discussed by T-lang in https://github.com/rust-lang/rust/issues/150553#issuecomment-3780810363.
cc @rust-lang/lang-ops (in case you want to do an FCP)
Fixesrust-lang/rust#150553
compiler/rustc_trait_selection/src/traits/vtable.rs@`vtable_entries`:
The impossible predicates check in `vtable_entries` used
`instantiate_own` which only includes the method's own where-clauses,
not the parent trait's bounds. Replace it with
`instantiate_and_check_impossible_predicates` which also checks the
trait ref itself, so unsatisfied supertrait bounds are caught
and the method is marked `Vacant` instead of ICEing.
The recent switch in default mangling meant that the check was no longer
working correctly. Resolve this by checking for both legacy- and
v0-mangled core symbols to the extent that this is possible.
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#148590 (Stabilize `atomic_try_update`and deprecate `fetch_update` starting 1.99.0)
- rust-lang/rust#150522 (Stabilize new inclusive range type and iterator type)
- rust-lang/rust#152235 (Convert to inline diagnostics in `rustc_parse`)
- rust-lang/rust#152267 (feat: Implement `int_from_ascii` for `NonZero<T>`)
- rust-lang/rust#151576 (Stabilize `core::hint::cold_path`)
- rust-lang/rust#151933 (Linker-plugin-based LTO: give an explanation how to use linker-plugin-lto with full LTO)
- rust-lang/rust#152010 (Ignore all debuginfo tests for LLDB that we do not run in CI)
- rust-lang/rust#152199 (Move `rustc_query_system::cache`.)
Move `rustc_query_system::cache`.
It only defines two types, `Cache` and `WithDepNode`. Neither has anything much to do with queries -- they use `DepNodeIndex`, that's all.
This commit moves the module into `rustc_middle`, to where they are used. It also renames the extremely non-descriptive `Cache` as `WithDepNodeCache`.
r? @Zalathar
Ignore all debuginfo tests for LLDB that we do not run in CI
We only run LLDB 1500 in CI. Any test with a min-lldb-version above that is currently ignored. It's not clear any of these tests actually work with that LLDB version, and they definitely don't work on LLDB ~2100. So, ignore them until we fix debuginfo testing.
Fixesrust-lang/rust#151966
Linker-plugin-based LTO: give an explanation how to use linker-plugin-lto with full LTO
Closesrust-lang/rust#138910
The existing linker-plugin-based LTO documentation does not describe the correct usage of full LTO. Specifically, when invoking `rustc` with full LTO, the `-C lto` flag must be passed in addition to `-C linker-plugin-lto`.
Also, this PR documents the use of full LTO when linking Rust with Fortran. Unfortunately, LLVM `flang` does not currently support ThinLTO, so full LTO is the only viable option in this case.
Toolchain combinations were slightly updated.
TODO:
- [x] check swiftc compiler. Almost unusable.
- [x] check how std lib is actually compiled
- [x] add note about LLD and bitcode
- [x] report bug to LLVM: https://github.com/llvm/llvm-project/issues/179800
<details>
<summary>Swiftc is unusable</summary>
https://www.swift.org/install/ gave me LLVM-17. During playing with swift main + rust static library, LLVM-23 removed main :D
```console
# thin LTO Rust:
rustc --crate-type=staticlib -Clinker-plugin-lto -Copt-level=3 ./ftn.rs
# full LTO swift:
swiftc -static libftn.a main.swift -lto=llvm-full -O -use-ld=/tmp/test/llvm-project/install/bin/ld.lld -Xlinker --gc-sections -Xlinker --as-needed -o sr
./sr
> ftn() returned: 77
# thin LTO swift:
swiftc -static libftn.a main.swift -lto=llvm-thin -O -use-ld=/tmp/test/llvm-project/install/bin/ld.lld -Xlinker --gc-sections -Xlinker --as-needed -o sr
./sr
> No output
```
</details>
Stabilize `core::hint::cold_path`
`cold_path` has been around unstably for a while and is a rather useful tool to have. It does what it is supposed to and there are no known remaining issues, so stabilize it here (including const).
Newly stable API:
```rust
// in core::hint
pub const fn cold_path();
```
I have opted to exclude `likely` and `unlikely` for now since they have had some concerns about ease of use that `cold_path` doesn't suffer from. `cold_path` is also significantly more flexible; in addition to working with boolean `if` conditions, it can be used in `match` arms, `if let`, closures, and other control flow blocks. `likely` and `unlikely` are also possible to implement in user code via `cold_path`, if desired.
Closes: https://github.com/rust-lang/rust/issues/136873 (tracking issue)
---
There has been some design and implementation work for making `#[cold]` function in more places, such as `if` arms, `match` arms, and closure bodies. Considering a stable `cold_path` will cover all of these usecases, it does not seem worth pursuing a more powerful `#[cold]` as an alternative way to do the same thing. If the lang team agrees, then:
Closes: https://github.com/rust-lang/rust/issues/26179
Closes: https://github.com/rust-lang/rust/pull/120193
feat: Implement `int_from_ascii` for `NonZero<T>`
- Tracking issue: rust-lang/rust#134821
This pull request adds `from_ascii` and `from_ascii_radix` methods to `NonZero<T>` that parses a non-zero integer from an ASCII-byte slice (`&[u8]`) with decimal digits or digits in a given base.
When using the combination of `int::from_ascii` or `int::from_ascii_radix` and `NonZero::<T>::new`, [`IntErrorKind::Zero`](https://doc.rust-lang.org/core/num/enum.IntErrorKind.html#variant.Zero) cannot be returned as an error.
`NonZero::<T>::from_str_radix` and `NonZero::<T>::from_str` require a string (`&str`) as a parameter.
```rust
// Cannot return `IntErrorKind::Zero` as an error.
assert_eq!(NonZero::new(u8::from_ascii(b"0").unwrap()), None);
// Can return `IntErrorKind::Zero` as an error.
let err = NonZero::<u8>::from_ascii(b"0").unwrap_err();
assert_eq!(err.kind(), &IntErrorKind::Zero);
```
See also rust-lang/rust#152193
Convert to inline diagnostics in `rustc_parse`
This was the most annoying one by far, had to make a few changes to the representation of two errors (no user-facing changes tho), these changes are in separate commits for clarity :)
For https://github.com/rust-lang/rust/issues/151366
r? @jdonszelmann
Stabilize new inclusive range type and iterator type
Part 1 of stabilizing the new range types for rust-lang/rust#125687
stabilizes `core::range::RangeInclusive` and `core::range::RangeInclusiveIter`. Newly stable API:
```rust
// in core and std
pub mod range;
// in core::range
pub struct RangeInclusive<Idx> {
pub start: Idx,
pub last: Idx,
}
impl<Idx: fmt::Debug> fmt::Debug for RangeInclusive<Idx> { /* ... */ }
impl<Idx: PartialOrd<Idx>> RangeInclusive<Idx> {
pub const fn contains<U>(&self, item: &U) -> bool
where
Idx: [const] PartialOrd<U>,
U: ?Sized + [const] PartialOrd<Idx>;
pub const fn is_empty(&self) -> bool
where
Idx: [const] PartialOrd;
}
impl<Idx: Step> RangeInclusive<Idx> {
pub fn iter(&self) -> RangeInclusiveIter<Idx>;
}
impl<T> const RangeBounds<T> for RangeInclusive<T> { /* ... */ }
impl<T> const RangeBounds<T> for RangeInclusive<&T> { /* ... */ }
impl<T> const From<RangeInclusive<T>> for legacy::RangeInclusive<T> { /* ... */ }
impl<T> const From<legacy::RangeInclusive<T>> for RangeInclusive<T> { /* ... */ }
pub struct RangeInclusiveIter<A>(/* ... */);
impl<A: Step> RangeInclusiveIter<A> {
pub fn remainder(self) -> Option<RangeInclusive<A>>;
}
impl<A: Step> Iterator for RangeInclusiveIter<A> {
type Item = A;
/* ... */
}
impl<A: Step> DoubleEndedIterator for RangeInclusiveIter<A> { /* ... */ }
impl<A: Step> FusedIterator for RangeInclusiveIter<A> { }
impl<A: Step> IntoIterator for RangeInclusive<A> {
type Item = A;
type IntoIter = RangeInclusiveIter<A>;
/* ... */
}
impl ExactSizeIterator for RangeInclusiveIter<u8> { }
impl ExactSizeIterator for RangeInclusiveIter<i8> { }
unsafe impl<T> const SliceIndex<[T]> for range::RangeInclusive<usize> {
type Output = [T];
/* ... */
}
unsafe impl const SliceIndex<str> for range::RangeInclusive<usize> {
type Output = str;
/* ... */
}
```
I've removed the re-exports temporarily because from what I can tell, there's no way to make re-exports of stable items unstable. They will be added back and stabilized in a separate PR.
Add avr_target_feature
This adds the following unstable target features (tracking issue: https://github.com/rust-lang/rust/issues/146889):
- The following two are particularly important for properly supporting inline assembly:
- `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also https://github.com/rust-lang/rust/pull/146901)
- `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also 2a528760bf)
- The followings help recognizing whether specific instructions are available:
- `addsubiw`
- `break`
- `eijmpcall`
- `elpm`
- `elpmx`
- `ijmpcall`
- `jmpcall`
- `lpm`
- `lpmx`
- `movw`
- `mul`
- `rmw`
- `spm`
- `spmx`
Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure.
- Report future-incompatible warning (https://github.com/rust-lang/rust/issues/116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM.
- See https://github.com/rust-lang/rust/pull/146900#issuecomment-3323558005 for details.
LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something.
(The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).)
cc @Patryk27 @Rahix
r? workingjubilee
@rustbot label +O-AVR +A-target-feature
The acosh functions were incorrectly returning finite values for some
negative inputs (should be NaN for any `x < 1.0`)
The bug was inherited when originally ported from musl, and this patch
follows their fix for single-precision acoshf in [1].
A similar fix is applied to acosh, though musl still has an incorrect
implementation requiring tests against that basis to be skipped.
[1]: https://git.musl-libc.org/cgit/musl/commit/?id=c4c38e6364323b6d83ba3428464e19987b981d7a
[ added context to message - Trevor ]
Stabilize const ControlFlow predicates
Tracking issue: rust-lang/rust#148738
Related: rust-lang/rust#140266 (moved the relevant const-unstables to that feature)
r? @dtolnay
Use relative paths for std links in rustc-docs
Fixesrust-lang/rust#151496
This adds `--extern-html-root-url` for each `STD_PUBLIC_CRATES` entry pointing to `../`, so that `rustc-docs` links to the locally installed `rust-docs` via relative paths.
r? @GuillaumeGomez @rami3l
Dont strip const blocks in array lengths
r? oli-obk
mGCA now handles const blocks by *always* handling them during `lower_expr_to_const_arg_direct` instead of *sometimes* stripping them out at parse time. This is just generally a lot clearer/nicer but also means parsing isn't lossy which is just straight up wrong.
We now use `MgcaDisambiguation::Direct` for const blocks because we "directly" represent a const block as `hir::ConstArgKind::Anon` :> The only time that an anon const for const generics uses `MgcaDisambiguation::AnonConst` is for unbraced literals.
Once we properly support literals in `hir::ConstArgKind` (see rust-lang/rust#152139rust-lang/rust#152001) then `MgcaDisambiguation` can be renamed to `AnonConstKind` with `TypeSystem` and `NonTypeSystem` variants. We can also get rid of `mgca_direct_lit_hack`. I expect this to be a very nice cleanup :)
Fixesrust-lang/rustfmt#6788
The diff relating to passing spans around is to avoid a bunch of mGCA diagnostics changing from `const {}` to `{}`. I'm not entirely sure why this was happening.
cc @rust-lang/rustfmt
How do I run the tests in the rustfmt repo from here? `x test rustfmt` only seems to run like 100 tests and doesn't result in a `target/issue-6788.rs` getting created. I've verified locally that this formats correctly though
In recent nightlies we are hitting errors like the following:
error: an associated constant with this name may be added to the standard library in the future
--> libm/src/math/support/float_traits.rs:248:48
|
248 | const SIGN_MASK: Self::Int = 1 << (Self::BITS - 1);
| ^^^^^^^^^^
...
324 | / float_impl!(
325 | | f32,
326 | | u32,
327 | | i32,
... |
333 | | fmaf32
334 | | );
| |_- in this macro invocation
|
= warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior!
= note: for more information, see issue #48919 <https://github.com/rust-lang/rust/issues/48919>
= note: `-D unstable-name-collisions` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unstable_name_collisions)]`
= note: this error originates in the macro `float_impl` (in Nightly builds, run with -Z macro-backtrace for more info)
help: use the fully qualified path to the associated const
|
248 - const SIGN_MASK: Self::Int = 1 << (Self::BITS - 1);
248 + const SIGN_MASK: Self::Int = 1 << (<f32 as float_traits::Float>::BITS - 1);
|
help: add `#![feature(float_bits_const)]` to the crate attributes to enable `core::f32::<impl f32>::BITS`
--> libm/src/lib.rs:26:1
|
26 + #![feature(float_bits_const)]
|
Using fully qualified syntax is verbose and `BITS` only exists since
recently, so allow this lint instead.
MGCA: require #[type_const] on free consts too
When investigating another issue, I discovered that following ICEs (the `const_of_item` query doesn't support non-type_const-marked constants and does a `span_delayed_bug`):
```rust
#![feature(min_generic_const_args)]
#![allow(incomplete_features)]
const N: usize = 4;
fn main() {
let x = [(); N];
}
```
My initial thought of "only require `#[type_const]` on places that stable doesn't currently accept" ran into the issue of this compiling on stable today:
```rust
trait Trait {
const N: usize;
}
impl<const PARAM: usize> Trait for [(); PARAM] {
const N: usize = PARAM;
}
fn main() {
let x = [(); <[(); 4] as Trait>::N];
}
```
Figuring out which specific cases are not currently accepted by stable is quite hairy.
Upon discussion with @BoxyUwU, she suggested that *all* consts, including free consts, should require `#[type_const]` to be able to be referred to. This is what this PR does.
---
~~The change to `tests/ui/const-generics/generic_const_exprs/non-local-const.rs` is unfortunate, reverting the fix in https://github.com/rust-lang/rust/pull/143106 no longer fails the test. Any suggestions to test it more appropriately would be most welcome!~~
edit: never mind, figured out how compiletests work :) - verified that the new test setup correctly ICEs when that PR's fix is reverted.
r? @BoxyUwU
bootstrap: Remove `ShouldRun::paths`
Split out from https://github.com/rust-lang/rust/pull/151930. I've copied my comment in https://github.com/rust-lang/rust/pull/151930#discussion_r2750409129 into the commit description.
r? @Zalathar cc @Mark-Simulacrum @Kobzol
---
Some history about `paths()`. The original intent @Mark-Simulacrum had
when he introduced PathSet in f104b12059, to my knowledge, was that multiple paths
could be aliases for the same step. That's what rustdoc is doing; both
paths for rustdoc run exactly the same Step, regardless of whether one
or both are present.
That never really caught on. To my knowledge, rustdoc is the only usage
of paths() there's ever been.
Later, in rust-lang/rust#95503, I repurposed PathSet to mean "each crate in this set
should be passed to Step::make_run in RunConfig". That was not the
previous meaning.
Rustdoc never looks at run.paths in make_run, so it's safe to just treat
it as an alias, like elsewhere in bootstrap. Same for all the other tool
steps.
Always use Xcode-provided Clang in macOS CI
Most of our macOS CI runners use the Xcode-provided Clang. `dist-apple-various` still downloads Clang from LLVM's prebuilt sources, which is a bit problematic, because we're still using the Xcode-provided _headers_.
As a concrete example, using Xcode's Clang is required by https://github.com/rust-lang/rust/pull/152013, as otherwise updating to Xcode 26 headers fails with an obscure `fatal error: 'net/route.h' file not found`, see [this build log](https://github.com/rust-lang/rust/pull/152013#issuecomment-3838801617). I suspect this is because building the new headers isn't officially supported with the older LLVM/Clang 15.
This PR removes that functionality, so that we instead always build with the Xcode-provided Clang. This is effectively the same as setting `USE_XCODE_CLANG=1` on `dist-apple-various` as well, but I thought I'd clean things up while I'm at it.
I didn't find the reason why we did this in first place, maybe because the Xcode Clang at the time was too out of date to build LLVM? It doesn't seem to be a problem anymore though.
r? t-infra
Fix ICE in normalizing inherent associated consts with `#[type_const]`
Fixesrust-lang/rust#151027Fixesrust-lang/rust#138089Fixesrust-lang/rust#138226Fixesrust-lang/rust#150960
When an inherent associated const is marked with `#[type_const]`, its generics expect args in the format `[Self, own_params...]`, similar to inherent associated types. However, HIR typeck's `instantiate_value_path` was constructing args in the regular associated const format `[impl_params..., own_params...]`. This mismatch caused ICEs when the `args` were later used in contexts expecting the IAC format, such as user type annotations and `borrowck`'s type ascription.
feat: Add `NonZero::<T>::from_str_radix`
- Accepted ACP: rust-lang/libs-team#548
- Tracking issue: rust-lang/rust#152193
This pull request adds a method to `NonZero<T>` that parses a non-zero integer from a string slice with digits in a given base.
When using the combination of `int::from_str_radix` and `NonZero::<T>::new`, [`IntErrorKind::Zero`](https://doc.rust-lang.org/core/num/enum.IntErrorKind.html#variant.Zero) cannot be returned as an error. When using `NonZero::<T>::from_str`, `IntErrorKind::Zero` can be returned as an error, but this method cannot parse non-decimal integers.
`NonZero::<T>::from_str_radix` can return `IntErrorKind::Zero` as an error, and can parse both decimal integers and non-decimal integers.
Update wasi-sdk used in CI/releases
This is similar to prior updates such as rust-lang/rust#149037 in that this is just updating a URL. This update though has some technical updates accompanying it as well, however:
* The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this target, even for startup. This means that the final binary no longer has an "adapter" which can help making instantiation of a component a bit more lean.
* In rust-lang/rust#147572 libstd was updated to use wasi-libc more often on the `wasm32-wasip2` target. This uncovered a number of bugs in wasi-libc such as rust-lang/rust#149864, rust-lang/rust#150291, and rust-lang/rust#151016. These are all fixed in wasi-sdk-30 so the workarounds in the standard library are all removed.
Overall this is not expected to have any sort of major impact on users of WASI targets. Instead it's expected to be a normal routine update to keep the wheels greased and oiled.
Some history about `paths()`. The original intent Mark-Simulacrum had
when he introduced PathSet, to my knowledge, was that multiple paths
could be aliases for the same step. That's what rustdoc is doing; both
paths for rustdoc run exactly the same Step, regardless of whether one
or both are present.
That never really caught on. To my knowledge, rustdoc is the only usage
of paths() there's ever been.
Later, in 95503, I repurposed PathSet to mean "each crate in this set
should be passed to Step::make_run in RunConfig". That was not the
previous meaning.
Rustdoc never looks at run.paths in make_run, so it's safe to just treat
it as an alias, like elsewhere in bootstrap. Same for all the other tool
steps.
Co-authored-by: Tshepang Mbambo <hopsi@tuta.io>
update openmp/offload builds to LLVM 22, Part 1
This part of the update of OpenMP/Offload to LLVM 22 does not depend on a backport in the future LLVM release candidate 3. Let's therefore merge it first, to unblock existing users/developers.
r? @jieyouxu
Port rustc_abi to the attribute parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
This attribute either dumps the abi info for functions (debug arg)
or if you put it on a pair of fn ptr's it checks they match (assert_eq arg)
r? @JonathanBrouwer
Consolidate type const checks on `tcx.is_type_const`
A little bit of cleanup; explanation can be found in the reporting issue.
Fixesrust-lang/rust#152124
r? BoxyUwU
Mark match arms in try and for as being from desugarings.
Some of the arms created by these desugarings have an expression which isn't marked as coming from the desugaring. e.g. try generates `Continue(val) => val` where the expression has the span of the original parameter (done for diagnostic purposes). Since the arm created just used that span they end up without a desugaring mark unnecessarily.
This is only a minor annoyance with some work I'm doing in clippy.
Provide more context on trait bounds being unmet due to imperfect derive
When encountering a value that has a borrow checker error where the type was previously moved, when suggesting cloning verify that it is not already being derived. If it is, explain why the `derive(Clone)` doesn't apply:
```
note: if `TypedAddress<T>` implemented `Clone`, you could clone the value
--> $DIR/derive-clone-implicit-bound.rs:6:1
|
LL | #[derive(Clone, Copy)]
| ----- derived `Clone` adds implicit bounds on type parameters
LL | pub struct TypedAddress<T>{
| ^^^^^^^^^^^^^^^^^^^^^^^^-^
| | |
| | introduces an implicit `T: Clone` bound
| consider manually implementing `Clone` for this type
...
LL | let old = self.return_value(offset);
| ------ you could clone this value
```
When encountering a bound coming from a derive macro, suggest manual impl of the trait.
Use the span for the specific param when adding bounds in builtin derive macros, so the diagnostic will point at them as well as the derive macro itself.
```
note: required for `Id<SomeNode>` to implement `PartialEq`
--> $DIR/derive-implicit-bound.rs:5:10
|
LL | #[derive(PartialEq, Eq)]
| ^^^^^^^^^
LL | pub struct Id<T>(PhantomData<T>);
| - unsatisfied trait bound introduced in this `derive` macro
= help: consider manually implementing `PartialEq` to avoid undesired bounds
```
Mention that the trait could be manually implemented in E0599.
Fixrust-lang/rust#108894. Address rust-lang/rust#143714. Address #rust-lang/rust#146515 (but ideally would also suggest constraining the fn bound correctly as well).
This is similar to prior updates such as 149037 in that this is just
updating a URL. This update though has some technical updates
accompanying it as well, however:
* The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this
target, even for startup. This means that the final binary no longer
has an "adapter" which can help making instantiation of a component a
bit more lean.
* In 147572 libstd was updated to use wasi-libc more often on the
`wasm32-wasip2` target. This uncovered a number of bugs in
wasi-libc such as 149864, 150291, and 151016. These are all fixed in
wasi-sdk-30 so the workarounds in the standard library are all
removed.
Overall this is not expected to have any sort of major impact on users
of WASI targets. Instead it's expected to be a normal routine update to
keep the wheels greased and oiled.
`HashStableContext` impls should be in `hcx.rs`, and `HashStable` impls
should be in `impls_syntax.rs`. This commit moves a few that are in the
wrong file.
It has a single impl, which does nothing, as you'd expect when hashing a
type called `HashIgnoredAttrId`!
So this commit just removes it, and `HashIgnoredAttrId::hash_stable`
ends up doing nothing (with a comment) instead of calling the trait
method to do nothing.
Calling `match` on a struct is a really weird thing to do. As the name
suggests, it's an assert, so let's write it as one. Also clarify the
comment a little.
It has a single use. It doesn't need to be public. It doesn't use `self`
and so doesn't need to be in the trait. And `IGNORED_ATTRIBUTES` can be
moved within it.
Replace `ToString::to_string` with `ToOwned::to_owned` when it is passed
as a function parameter.
```rust
fn issue16511(x: Option<&str>) -> Option<String> {
// Replace with ToOwned::to_owned
x.map(ToString::to_string)
}
```
fixesrust-lang/rust-clippy#16511
---
changelog: [`str_to_string`]: handle a case when `ToString::to_string`
is passed as function parameter
Detect Python-style f-string debug syntax in format strings and emit a
clear diagnostic explaining that it is not supported in Rust. When the
intended operation can be inferred, suggest the corresponding Rust
alternative e.g from `println!("{=}", x)` to `dbg!({x})`.
Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>
we will add an explicit incompatibility of softfloat and vector feature
in rutsc s390x-unknown-none-softfloat target specification.
Therefore we need to disable vector intrinsics here to be able to compile
core for this target.
library/std: Rename `ON_BROKEN_PIPE_FLAG_USED` to `ON_BROKEN_PIPE_USED`
This commit is a pure internal rename and does not change any functionality.
The `FLAG_` part of `ON_BROKEN_PIPE_FLAG_USED` comes from that the compiler flag `-Zon-broken-pipe=...` is used to enable the feature.
Remove the `FLAG_` part so the name works both for the current compiler flag `-Zon-broken-pipe=...` and for the upcoming [Externally Implementable Item `#[std::io::on_broken_pipe]`](https://github.com/rust-lang/rust/pull/150591) PR. This makes the diff of that PR smaller.
The local variable name `sigpipe_attr_specified` comes from way back when the feature was controlled with an `fn main()` attribute called `#[unix_sigpipe = "..."]`. Rename that too.
Incorporate query description functions into `QueryVTable`
Putting a `desc` function in each query vtable reduces the amount of parameter juggling required when creating query stack frames, because almost all of the necessary information can be found in the vtable.
There should be no change to compiler output.
c-variadic: make `va_arg` match on `Arch` exhaustive
tracking issue: https://github.com/rust-lang/rust/issues/44930
Continuing from https://github.com/rust-lang/rust/pull/150094, the more annoying cases remain. These are mostly very niche targets without Clang `va_arg` implementations, and so it might just be easier to defer to LLVM instead of us getting the ABI subtly wrong. That does mean we cannot stabilize c-variadic on those targets I think.
Alternatively we could ask target maintainers to contribute an implementation. I'd honestly prefer they make that change to LVM though (likely by just using `CodeGen::emitVoidPtrVAArg`) that we can mirror.
r? @workingjubilee
Remove rustdoc GUI flaky test
Part of rust-lang/rust#93784.
Originally, this test was checking more things (original version is [here](6bbbff5189)), now it only checks that the `searchIndex` variable is global. However, we already are forced to check it in the `rustddoc-js[-std]` testsuites so I think it's safe to say that it's superfluous and definitely not worth all the CI flakyness it created.
r? ghost
bootstrap: exclude hexagon-unknown-qurt from llvm-libunwind default
Hexagon Linux targets (hexagon-unknown-linux-musl) use in-tree llvm-libunwind for stack unwinding. However, hexagon-unknown-qurt uses libc_eh from the Hexagon SDK instead.
Fix incorrect RSS on systems with non-4K page size
`get_resident_set_size` computed RSS by multiplying the number of pages from `/proc/self/statm` with a hard-coded 4096-byte page size. This produces incorrect results on systems where the runtime page size is not 4 KiB.
Use `sysconf(_SC_PAGESIZE)` to determine the actual page size at runtime so the RSS reported in `-Z time-passes` output is accurate across platforms.
Port reexport_test_harness_main to attr parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
I don't think I can use the parsed form in compiler/rustc_builtin_macros/src/test_harness.rs since that has to use the AST attrs?
r? @JonathanBrouwer
Port depgraph testing attributes to parser
Tracking issue: rust-lang/rust#131229
Ports `#[rustc_clean]`, `#[rustc_if_this_changed]` and `#[rustc_then_this_would_need]` attributes.
Removes references to `rustc_dirty` as that attribute was folded into `rustc_clean` some time ago and rename some code accordingly.
r? JonathanBrouwer
Some `rustc_query_system` cleanups
Small improvements I found while looking closely at `rustc_query_system`. Best reviewed one commit at a time.
r? @cjgillot
Remove dummy loads on offload codegen
The current logic generates two dummy loads to prevent some globals from being optimized away. This blocks memtransfer loop hoisting optimizations, so it's time to remove them.
r? @ZuseZ4
Rename trait `DepNodeParams` to `DepNodeKey`
In query system plumbing, we usually refer to a query's explicit argument value as a “key”.
The first few commits do some preliminary cleanup that would conflict with the rename; the rename itself is in the final commit.
r? nnethercote (or compiler)
Return `ExitCode` from `rustc_driver::main` instead of calling `process::exit`
This makes rustc simply return an exit code from main rather than calling `std::process::exit` with an exit code. This means that drops run normally and the process exits cleanly. This is similar to what happens when an ICE occurs (due to being a panic that's caught by std's `lang_start`).
Also instead of hard coding success and failure codes this uses `ExitCode::SUCCESS` and `ExitCode::FAILURE`, which in turn effectively uses `libc::EXIT_SUCCESS` and `libc::EXIT_FAILURE` (via std). These are `0` and `1` respectively for all currently supported host platforms so it doesn't actually change the exit code.
Return `ExitCode` from `rustc_driver::main` instead of calling `process::exit`
This makes rustc simply return an exit code from main rather than calling `std::process::exit` with an exit code. This means that drops run normally and the process exits cleanly. This is similar to what happens when an ICE occurs (due to being a panic that's caught by std's `lang_start`).
Also instead of hard coding success and failure codes this uses `ExitCode::SUCCESS` and `ExitCode::FAILURE`, which in turn effectively uses `libc::EXIT_SUCCESS` and `libc::EXIT_FAILURE` (via std). These are `0` and `1` respectively for all currently supported host platforms so it doesn't actually change the exit code.
Replace `ToString::to_string` with `ToOwned::to_owned` when the function is passed as is:
```rust
fn issue16511(x: Option<&str>) -> String {
// Replace with ToOwned::to_owned
x.map(ToString::to_string)
}
```
Use fewer intermediate functions for short backtraces in queries
If we make sure that `compute_fn` in the query's vtable is actually named `__rust_begin_short_backtrace`, we can avoid the need for some additional intermediate functions and stack frames.
This is similar to how the `get_query_incr` and `get_query_non_incr` functions are actually named `__rust_end_short_backtrace`.
---
Before/after comparison: https://github.com/rust-lang/rust/pull/151739#issuecomment-3815432527
---
- Earlier draft of this PR: https://github.com/rust-lang/rust/pull/151719
- Introduction of this backtrace-trimming: https://github.com/rust-lang/rust/pull/108938
They are defined in `rustc_query_system` but used in `rustc_query_impl`.
This is very much *not* how things are supposed to be done; I suspect
someone got lazy and took a shortcut at some point.
This commit moves the errors into `rustc_query_impl`. This requires more
lines of code to give `rustc_query_impl` an errors module, but it's
worthwhile to do things in the normal way instead of a weird exceptional
way.
It's a tiny module with one trait and a default impl. It's not used in
`rustc_query_system`; all uses and non-default impls are in
`rustc_middle` and `rustc_query_impl`.
This commit moves it into `rustc_middle`, which makes things simpler
overall.
And add a test. This is followup work to PR 151704. It introduced a regression where
cargo is now unwilling to build cdylibs for Emscripten because `crt_static_default` is
`true` but `crt_static_allows_dylibs` is `false`. Unfortunately the added test does not
fail without the change because the validation logic is in Cargo, not in rustc. But it's
good to have some coverage of this anyways.
This commmit is a pure rename and does not change any functionality.
The `FLAG_` part of `ON_BROKEN_PIPE_FLAG_USED` comes from that the
compiler flag `-Zon-broken-pipe=...` is used to enable the feature.
Remove the `FLAG_` part so the name works both for the flag
`-Zon-broken-pipe=...` and for the upcoming Externally Implementable
Item `#[std::io::on_broken_pipe]`. This makes the diff of that PR
smaller.
The local variable name `sigpipe_attr_specified` comes from way back
when the feature was controlled with an `fn main()` attribute called
`#[unix_sigpipe = "..."]`. Rename that too.
skip codegen for intrinsics with big fallback bodies if backend does not need them
This hopefully fixes the perf regression from https://github.com/rust-lang/rust/pull/148478. I only added the intrinsics with big fallback bodies to the list; it doesn't seem worth the effort of going through the entire list.
Fixes https://github.com/rust-lang/rust/issues/149945
Cc @scottmcm @bjorn3
We only use mir_for_ctfe for them anyway in instance_mir. This does
prevent MIR inlining of constructor calls, but constructor calls that
are inlinable during MIR optimizations are rare anyway given that MIR
building already inlines all direct calls to constructors.
`get_resident_set_size` computed RSS by multiplying the number of pages
from `/proc/self/statm` with a hard-coded 4096-byte page size. This
produces incorrect results on systems where the runtime page size is
not 4 KiB.
Use `sysconf(_SC_PAGESIZE)` to determine the actual page size at runtime
so the RSS reported in `-Z time-passes` output is accurate across
platforms.
Hexagon Linux targets (hexagon-unknown-linux-musl) use in-tree
llvm-libunwind for stack unwinding. However, hexagon-unknown-qurt
uses libc_eh from the Hexagon SDK instead.
Fix set_times_nofollow for directory on windows
Fix issue from:
https://github.com/rust-lang/rust/issues/147455#issuecomment-3841311858
old code `opts.write(true)` on Windows requests `GENERIC_WRITE` access, replace with `opts.access_mode(c::FILE_WRITE_ATTRIBUTES)` to get minimal permission.
r? @joshtriplett
citool: report debuginfo test statistics
Extend CI postprocessing to aggregate pass/fail/ignored counts for debuginfo tests. Tests are identified via their reported suite names (e.g. debuginfo-gdb, debuginfo-lldb or debuginfo-cdb).
Fix autodiff codegen tests
Preparing autodiff for release on nightly. Since we haven't been running these tests in CI, they regressed over the last months. These changes fixes this and hopefully make the tests more robust for the future.
r? compiler
link modifier `export-symbols`: export all global symbols from selected uptream c static libraries
In order to be able to export symbols from a specified upstream C static library, I redesigned a solution that, compared to a previous PR rust-lang/rust#150335 I submitted, will not have any extra symbols leaking out.
The following points should be noted:
- This attribute will select and import the `Global` symbols of the first matching library it finds.
- Developers should ensure that there are no libraries with the same name.
- This modifier is only compatible with `static` linking kind
- By default, upstream C static libraries will not export their `Global` symbols regardless of whether `LTO` optimization is enabled. However, after enabling this attribute, if the upstream C static library has `LTO` optimization enabled, the compiler will issue an error to inform the developer that the linked C library is invalid.
The test code is the same as the PR rust-lang/rust#150335.
Here are the results:
1. `cargo +include-libs rustc --release -- -L. -lstatic:+export-symbols=c_add`
(or you can use `#[link(name = "c_add", kind= "static", modifier = "+export-symbols")]` in the file)
```bash
U abort@GLIBC_2.2.5
U bcmp@GLIBC_2.2.5
0000000000014f60 T c_add
U calloc@GLIBC_2.2.5
U close@GLIBC_2.2.5
0000000000014f70 T c_sub
w __cxa_finalize@GLIBC_2.2.5
w __cxa_thread_atexit_impl@GLIBC_2.18
U dl_iterate_phdr@GLIBC_2.2.5
0000000000014ee0 T downstream_add
U __errno_location@GLIBC_2.2.5
U free@GLIBC_2.2.5
U fstat64@GLIBC_2.33
U getcwd@GLIBC_2.2.5
U getenv@GLIBC_2.2.5
w __gmon_start__
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U lseek64@GLIBC_2.2.5
U malloc@GLIBC_2.2.5
U memcpy@GLIBC_2.14
U memmove@GLIBC_2.2.5
U memset@GLIBC_2.2.5
U mmap64@GLIBC_2.2.5
U munmap@GLIBC_2.2.5
U open64@GLIBC_2.2.5
U posix_memalign@GLIBC_2.2.5
U pthread_key_create@GLIBC_2.34
U pthread_key_delete@GLIBC_2.34
U pthread_setspecific@GLIBC_2.34
U read@GLIBC_2.2.5
U readlink@GLIBC_2.2.5
U realloc@GLIBC_2.2.5
U realpath@GLIBC_2.3
U stat64@GLIBC_2.33
w statx@GLIBC_2.28
U strlen@GLIBC_2.2.5
U syscall@GLIBC_2.2.5
U __tls_get_addr@GLIBC_2.3
U _Unwind_Backtrace@GCC_3.3
U _Unwind_DeleteException@GCC_3.0
U _Unwind_GetDataRelBase@GCC_3.0
U _Unwind_GetIP@GCC_3.0
U _Unwind_GetIPInfo@GCC_4.2.0
U _Unwind_GetLanguageSpecificData@GCC_3.0
U _Unwind_GetRegionStart@GCC_3.0
U _Unwind_GetTextRelBase@GCC_3.0
U _Unwind_RaiseException@GCC_3.0
U _Unwind_Resume@GCC_3.0
U _Unwind_SetGR@GCC_3.0
U _Unwind_SetIP@GCC_3.0
U write@GLIBC_2.2.5
U writev@GLIBC_2.2.5
```
3. `cargo +nightly rustc --release -- -L ./`
```bash
U abort@GLIBC_2.2.5
U bcmp@GLIBC_2.2.5
U calloc@GLIBC_2.2.5
U close@GLIBC_2.2.5
w __cxa_finalize@GLIBC_2.2.5
w __cxa_thread_atexit_impl@GLIBC_2.18
U dl_iterate_phdr@GLIBC_2.2.5
0000000000011e10 T downstream_add
U __errno_location@GLIBC_2.2.5
U free@GLIBC_2.2.5
U fstat64@GLIBC_2.33
U getcwd@GLIBC_2.2.5
U getenv@GLIBC_2.2.5
w gettid@GLIBC_2.30
w __gmon_start__
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U lseek64@GLIBC_2.2.5
U malloc@GLIBC_2.2.5
U memcpy@GLIBC_2.14
U memmove@GLIBC_2.2.5
U memset@GLIBC_2.2.5
U mmap64@GLIBC_2.2.5
U munmap@GLIBC_2.2.5
U open64@GLIBC_2.2.5
U posix_memalign@GLIBC_2.2.5
U pthread_key_create@GLIBC_2.34
U pthread_key_delete@GLIBC_2.34
U pthread_setspecific@GLIBC_2.34
U read@GLIBC_2.2.5
U readlink@GLIBC_2.2.5
U realloc@GLIBC_2.2.5
U realpath@GLIBC_2.3
U stat64@GLIBC_2.33
w statx@GLIBC_2.28
U strlen@GLIBC_2.2.5
U syscall@GLIBC_2.2.5
U __tls_get_addr@GLIBC_2.3
U _Unwind_Backtrace@GCC_3.3
U _Unwind_GetDataRelBase@GCC_3.0
U _Unwind_GetIP@GCC_3.0
U _Unwind_GetIPInfo@GCC_4.2.0
U _Unwind_GetLanguageSpecificData@GCC_3.0
U _Unwind_GetRegionStart@GCC_3.0
U _Unwind_GetTextRelBase@GCC_3.0
U _Unwind_RaiseException@GCC_3.0
U _Unwind_Resume@GCC_3.0
U _Unwind_SetGR@GCC_3.0
U _Unwind_SetIP@GCC_3.0
U write@GLIBC_2.2.5
U writev@GLIBC_2.2.5
```
r? @bjorn3
If we make sure that `compute_fn` in the query's vtable is actually named
`__rust_begin_short_backtrace`, we can avoid the need for some additional
intermediate functions and stack frames.
This is similar to how the `get_query_incr` and `get_query_non_incr` functions
are actually named `__rust_end_short_backtrace`.
Assignments to a captured variable within a diverging closure should not
be considered unused if the divergence is caught.
This patch considers such assignments/captures to be used by diverging
closures irrespective of whether the divergence is caught, but better a
false negative unused lint than a false positive one (the latter having
caused a stable-to-stable regression).
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#151893 (Move the query list into a new `rustc_middle::queries` module)
- rust-lang/rust#152060 (ci: Optimize loongarch64-linux dist builders)
- rust-lang/rust#151993 (Add uv to the list of possible python runners)
- rust-lang/rust#152047 (Convert to inline diagnostics in `rustc_interface`)
- rust-lang/rust#152053 (Avoid semicolon suggestion when tail expr is error)
Failed merges:
- rust-lang/rust#152023 (Some `rustc_query_system` cleanups)
Avoid semicolon suggestion when tail expr is error
Fixesrust-lang/rust#151610
When the tail expression is Err due to recovery, HIR constructs `StmtKind::Semi(Err(..))`. The suggestion path then uses `stmt.span.with_lo(tail_expr.span.hi())` to target the semicolon, but `stmt.span == tail_expr.span` so the derived span is empty/invalid.
Add uv to the list of possible python runners
Fixes the unlikely case that one has uv, but not python, globally installed
(It's me, I'm the unlikely case)
ci: Optimize loongarch64-linux dist builders
Tune the build configuration for loongarch64-linux targets to speed up rustc.
Changes include:
- Enable jemalloc and rust thin-lto.
- Set codegen-units=1.
These changes reduce rustc-perf compile time by ~17%.
Move the query list into a new `rustc_middle::queries` module
This moves the query list from `rustc_middle::query` into a new `rustc_middle::queries` module. This splits up the use of the query system from the remaining implementation of it in `rustc_middle::query`, which conceptually belong to `rustc_query_system`.
The goal is to let rustc crates define queries with their own `queries` module, and this makes `rustc_middle` also fit this pattern.
The inner `queries` module used by the macros are renamed to `query_info`, so it doesn't conflict with the new outer name.
Pass on the `feedable` query modifier to macros
This passes on the `feedable` query modifier to macros so `QueryConfig.feedable` gives the correct result. Currently it's always false even for feedable queries.
Fixing this bug enables some consistency checks for feedable queries that were previously not being performed, which has a perf impact.
Tune the build configuration for loongarch64-linux targets to speed up rustc.
Changes include:
- Enable jemalloc and rust thin-lto.
- Set codegen-units=1 and disable debug assertions.
These changes reduce rustc-perf compile time by ~17%.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#148967 (const-eval: always do mem-to-mem copies if there might be padding involved)
- rust-lang/rust#152012 (Use `DEVELOPER_DIR` instead of a custom `xcode-select` script)
- rust-lang/rust#152044 (Convert to inline diagnostics in `rustc_incremental`)
- rust-lang/rust#152046 (Use glob imports for attribute parsers)
- rust-lang/rust#152054 (Distinguish error message for `#[diagnostic::on_const]` on const trait impls)
- rust-lang/rust#152059 (Fix some autodiff tests require Clto=fat)
- rust-lang/rust#152073 (Convert to inline diagnostics in `rustc_mir_dataflow`)
Extend CI postprocessing to aggregate pass/fail/ignored counts
for debuginfo tests. Tests are identified via their reported
suite names (e.g. debuginfo-gdb, debuginfo-lldb or debuginfo-cdb).
Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>
We were already setting `CARGO_TARGET_{target}_LINKER` when there is a
setting in `bootstrap.toml`, and when the host and target are the same,
this is also used for build scripts and proc-macros.
However, the host value wasn't set when building for any other target,
and Cargo would see that as a fingerprint change for those build
artifacts, rebuilding them.
If we always set the `CARGO_TARGET_{host}_LINKER`, then those build
scripts will keep a consistent Cargo fingerprint, so they'll remain
cached no matter how we're alternating targets.
Fix some autodiff tests require Clto=fat
It seems that some tests in tests/run-make/autodiff/type-trees/ require -Clto=fat at least on macos
There are several types of errors in tests/run-make/autodiff now. I fixed the easiest one to reduce the noise. I'll look into another errors after this PR.
I confirmed tests have passed.
```shell
./x test --stage 1 tests/run-make/autodiff/type-trees/array-typetree -- --ignored
./x test --stage 1 tests/run-make/autodiff/type-trees/mixed-struct-typetree -- --ignored
./x test --stage 1 tests/run-make/autodiff/type-trees/nott-flag -- --ignored
./x test --stage 1 tests/run-make/autodiff/type-trees/recursion-typetree -- --ignored
./x test --stage 1 tests/run-make/autodiff/type-trees/scalar-types -- --ignored
./x test --stage 1 tests/run-make/autodiff/type-trees/slice-typetree -- --ignored
./x test --stage 1 tests/run-make/autodiff/type-trees/struct-typetree -- --ignored
./x test --stage 1 tests/run-make/autodiff/type-trees/tuple-typetree -- --ignored
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.11s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
Building stage1 compiler artifacts (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.43s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 wasm-component-ld (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.10s
Building stage1 llvm-bitcode-linker (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.14s
Building stage1 run_make_support (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.10s
Building stage1 library artifacts (stage1 -> stage1, aarch64-apple-darwin)
Finished `dist` profile [optimized] target(s) in 0.21s
Building stage1 compiletest (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.34s
Building stage1 rustdoc_tool_binary (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.35s
Testing stage1 with compiletest suite=run-make mode=run-make (aarch64-apple-darwin)
running 1 tests
.
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 460 filtered out; finished in 2.32s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
NOTE: this message was printed twice to make it more likely to be seen
Build completed successfully in 0:00:12
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.12s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
Building stage1 compiler artifacts (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 1.05s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 wasm-component-ld (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.29s
Building stage1 llvm-bitcode-linker (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.29s
Building stage1 run_make_support (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.09s
Building stage1 library artifacts (stage1 -> stage1, aarch64-apple-darwin)
Finished `dist` profile [optimized] target(s) in 0.09s
Building stage1 compiletest (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.23s
Building stage1 rustdoc_tool_binary (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.14s
Testing stage1 with compiletest suite=run-make mode=run-make (aarch64-apple-darwin)
running 1 tests
.
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 460 filtered out; finished in 2.37s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
NOTE: this message was printed twice to make it more likely to be seen
Build completed successfully in 0:00:12
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.11s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
Building stage1 compiler artifacts (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.81s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 wasm-component-ld (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.35s
Building stage1 llvm-bitcode-linker (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.24s
Building stage1 run_make_support (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.10s
Building stage1 library artifacts (stage1 -> stage1, aarch64-apple-darwin)
Finished `dist` profile [optimized] target(s) in 0.19s
Building stage1 compiletest (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.25s
Building stage1 rustdoc_tool_binary (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.15s
Testing stage1 with compiletest suite=run-make mode=run-make (aarch64-apple-darwin)
running 1 tests
.
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 460 filtered out; finished in 1.34s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
NOTE: this message was printed twice to make it more likely to be seen
Build completed successfully in 0:00:13
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.28s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
Building stage1 compiler artifacts (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.38s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 wasm-component-ld (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.28s
Building stage1 llvm-bitcode-linker (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.23s
Building stage1 run_make_support (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.49s
Building stage1 library artifacts (stage1 -> stage1, aarch64-apple-darwin)
Finished `dist` profile [optimized] target(s) in 0.19s
Building stage1 compiletest (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.41s
Building stage1 rustdoc_tool_binary (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.36s
Testing stage1 with compiletest suite=run-make mode=run-make (aarch64-apple-darwin)
running 1 tests
.
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 460 filtered out; finished in 2.30s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
NOTE: this message was printed twice to make it more likely to be seen
Build completed successfully in 0:00:13
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.22s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
Building stage1 compiler artifacts (stage0 -> stage1, aarch64-apple-darwin)
Compiling rustc_session v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_session)
Compiling rustc_query_system v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_query_system)
Compiling rustc_parse v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_parse)
Compiling rustc_middle v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_middle)
Compiling rustc_attr_parsing v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_attr_parsing)
Compiling rustc_ast_passes v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_ast_passes)
Compiling rustc_transmute v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_transmute)
Compiling rustc_infer v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_infer)
Compiling rustc_expand v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_expand)
Compiling rustc_incremental v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_incremental)
Compiling rustc_mir_dataflow v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_mir_dataflow)
Compiling rustc_symbol_mangling v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_symbol_mangling)
Compiling rustc_ast_lowering v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_ast_lowering)
Compiling rustc_pattern_analysis v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_pattern_analysis)
Compiling rustc_public_bridge v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_public_bridge)
Compiling rustc_query_impl v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_query_impl)
Compiling rustc_monomorphize v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_monomorphize)
Compiling rustc_public v0.1.0-preview (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_public)
Compiling rustc_metadata v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_metadata)
Compiling rustc_trait_selection v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_trait_selection)
Compiling rustc_builtin_macros v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_builtin_macros)
Compiling rustc_resolve v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_resolve)
Compiling rustc_lint v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_lint)
Compiling rustc_ty_utils v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_ty_utils)
Compiling rustc_privacy v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_privacy)
Compiling rustc_codegen_ssa v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_codegen_ssa)
Compiling rustc_const_eval v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_const_eval)
Compiling rustc_sanitizers v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_sanitizers)
Compiling rustc_hir_analysis v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_hir_analysis)
Compiling rustc_traits v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_traits)
Compiling rustc_borrowck v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_borrowck)
Compiling rustc_mir_transform v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_mir_transform)
Compiling rustc_hir_typeck v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_hir_typeck)
Compiling rustc_codegen_llvm v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_codegen_llvm)
Compiling rustc_mir_build v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_mir_build)
Compiling rustc_passes v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_passes)
Compiling rustc_interface v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_interface)
Compiling rustc_driver_impl v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_driver_impl)
Compiling rustc_driver v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc_driver)
Compiling rustc-main v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/compiler/rustc)
Finished `release` profile [optimized] target(s) in 2m 51s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 wasm-component-ld (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.37s
Building stage1 llvm-bitcode-linker (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.17s
Building stage1 run_make_support (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.42s
Building stage1 library artifacts (stage1 -> stage1, aarch64-apple-darwin)
Compiling shlex v1.3.0
Compiling core v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/core)
Compiling libc v0.2.178
Compiling object v0.37.3
Compiling std v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/std)
Compiling test v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/test)
Compiling cc v1.2.0
Compiling compiler_builtins v0.1.160 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/compiler-builtins/compiler-builtins)
Compiling rustc-std-workspace-core v1.99.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/rustc-std-workspace-core)
Compiling alloc v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/alloc)
Compiling adler2 v2.0.1
Compiling memchr v2.7.6
Compiling panic_abort v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/panic_abort)
Compiling rustc-demangle v0.1.27
Compiling cfg-if v1.0.4
Compiling rustc-literal-escaper v0.0.7
Compiling unwind v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/unwind)
Compiling rustc-std-workspace-alloc v1.99.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/rustc-std-workspace-alloc)
Compiling panic_unwind v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/panic_unwind)
Compiling gimli v0.32.3
Compiling hashbrown v0.16.1
Compiling std_detect v0.1.5 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/std_detect)
Compiling miniz_oxide v0.8.9
Compiling addr2line v0.25.1
Compiling rustc-std-workspace-std v1.99.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/rustc-std-workspace-std)
Compiling proc_macro v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/proc_macro)
Compiling getopts v0.2.24
Compiling sysroot v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/library/sysroot)
Finished `dist` profile [optimized] target(s) in 34.54s
Building stage1 compiletest (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.40s
Building stage1 rustdoc_tool_binary (stage0 -> stage1, aarch64-apple-darwin)
Compiling rustdoc v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/src/librustdoc)
Compiling rustdoc-tool v0.0.0 (/Volumes/WD_BLACK_SN850X_HS_1TB/autodiff-rust/rust/src/tools/rustdoc)
Finished `release` profile [optimized] target(s) in 37.79s
Testing stage1 with compiletest suite=run-make mode=run-make (aarch64-apple-darwin)
running 5 tests
.....
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 456 filtered out; finished in 2.41s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
NOTE: this message was printed twice to make it more likely to be seen
Build completed successfully in 0:04:18
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.12s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
Building stage1 compiler artifacts (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.71s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 wasm-component-ld (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.11s
Building stage1 llvm-bitcode-linker (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.07s
Building stage1 run_make_support (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.09s
Building stage1 library artifacts (stage1 -> stage1, aarch64-apple-darwin)
Finished `dist` profile [optimized] target(s) in 0.15s
Building stage1 compiletest (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.34s
Building stage1 rustdoc_tool_binary (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.28s
Testing stage1 with compiletest suite=run-make mode=run-make (aarch64-apple-darwin)
running 1 tests
.
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 460 filtered out; finished in 2.04s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
NOTE: this message was printed twice to make it more likely to be seen
Build completed successfully in 0:00:13
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.11s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
Building stage1 compiler artifacts (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.82s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 wasm-component-ld (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.38s
Building stage1 llvm-bitcode-linker (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.08s
Building stage1 run_make_support (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.09s
Building stage1 library artifacts (stage1 -> stage1, aarch64-apple-darwin)
Finished `dist` profile [optimized] target(s) in 0.09s
Building stage1 compiletest (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.21s
Building stage1 rustdoc_tool_binary (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.14s
Testing stage1 with compiletest suite=run-make mode=run-make (aarch64-apple-darwin)
running 1 tests
.
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 460 filtered out; finished in 1.37s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
NOTE: this message was printed twice to make it more likely to be seen
Build completed successfully in 0:00:12
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.15s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
Building stage1 compiler artifacts (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.37s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 wasm-component-ld (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.35s
Building stage1 llvm-bitcode-linker (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.35s
Building stage1 run_make_support (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.29s
Building stage1 library artifacts (stage1 -> stage1, aarch64-apple-darwin)
Finished `dist` profile [optimized] target(s) in 0.12s
Building stage1 compiletest (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.46s
Building stage1 rustdoc_tool_binary (stage0 -> stage1, aarch64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.23s
Testing stage1 with compiletest suite=run-make mode=run-make (aarch64-apple-darwin)
running 1 tests
.
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 460 filtered out; finished in 1.41s
WARNING: The `change-id` is missing in the `bootstrap.toml`. This means that you will not be able to track the major changes made to the bootstrap configurations.
NOTE: to silence this warning, add `change-id = 148671` or `change-id = "ignore"` at the top of `bootstrap.toml`
NOTE: this message was printed twice to make it more likely to be seen
Build completed successfully in 0:00:12
```
Distinguish error message for `#[diagnostic::on_const]` on const trait impls
context: https://github.com/rust-lang/rust/pull/149627#discussion_r2589712535
Sorry for the delay between receiving the review and submitting this patch. I'll ask the original proposer to review it.
r? estebank
Use `DEVELOPER_DIR` instead of a custom `xcode-select` script
`DEVELOPER_DIR` is the standard environment variable for overriding the Xcode version, there is no need to invoke `xcode-select --switch` manually to do this.
The variable is documented in both `man xcode-select` and `man xcrun`.
Using this makes reproducing things locally a little easier (you can just copy the env var).
r? shepmaster
const-eval: always do mem-to-mem copies if there might be padding involved
This is the final piece of the puzzle for https://github.com/rust-lang/rust/issues/148470: when copying data of a type that has padding, always do a mem-to-mem copy, so that we always preserve the source padding exactly. That prevents rustc implementation choices from leaking into user-visible behavior.
This is technically a breaking change: the example at the top of https://github.com/rust-lang/rust/issues/148470 no longer compiles with this. However, it seems very unlikely that anyone would have depended on this. My main concern is not backwards compatibility, it is performance.
Fixesrust-lang/rust#148470
---
> Actually that seems to be entirely fine, it even helps with some benchmarks! I guess the mem-to-mem codepath is actually faster than the scalar pair codepath for the copy itself. It can slow things down later since now we have to do everything bytewise, but that doesn't show up in our benchmarks and might not be very relevant after all (in particular, it only affects types with padding, so the rather common wide pointers still always use the efficient scalar representation).
>
> So that would be my proposal to for resolving this issue then: to make const-eval behavior consistent, we always copy the padding from the source to the target. IOW, potentially pre-existing provenance in the target always gets overwritten (that part is already in https://github.com/rust-lang/rust/pull/148259), and potentially existing provenance in padding in the source always gets carried over (that's https://github.com/rust-lang/rust/pull/148967). If there's provenance elsewhere in the source our existing handling is fine:
> - If it's in an integer, that's UB during const-eval so we can do whatever.
> - If it's in a pointer, the the fragments must combine back together to a pointer or else we have UB.
> - If it's in a union we just carry it over unchanged.
>
> @traviscross we should check that this special const-eval-only UB is properly reflected in the reference. Currently we have [this](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html#r-undefined.const-transmute-ptr2int) but that only talks about int2ptr, not about invalid pointer fragments at pointer type. I also wonder if this shouldn't rather be part of ["invalid values"](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html#r-undefined.validity) to make it clear that this applies recursively inside fields as well.
> EDIT: Reference PR is up at https://github.com/rust-lang/reference/pull/2091.
_Originally posted by @RalfJung in [#148470](https://github.com/rust-lang/rust/issues/148470#issuecomment-3538447283)_
> Worth noting that this does not resolve the concerns @theemathas had about `-Zextra-const-ub-checks` sometimes causing *more* code to compile. Specifically, with that flag, the behavior changes to "potentially existing provenance in padding in the source never gets carried over". However, it's a nightly-only flag (used by Miri) so while the behavior is odd, I don't think this is a problem.
_Originally posted by @RalfJung in [#148470](https://github.com/rust-lang/rust/issues/148470#issuecomment-3538450164)_
---
Related:
- https://github.com/rust-lang/rust/issues/148470
- https://github.com/rust-lang/reference/pull/2091
`DEVELOPER_DIR` is the standard environment variable for overriding the
Xcode version, there is no need to invoke `xcode-select --switch`
manually to do this.
The variable is documented in both `man xcode-select` and `man xcrun`.
Convert to inline diagnostics in `rustc_attr_parsing`
Converts a crate for rust-lang/rust#151366
This PR is almost completely autogenerated by a hacky script I have locally :)
error on unsized AnonConsts
The constant evaluator does not support unsized types, however, unsized AnonConsts were never checked to be Sized, so no errors were generated on them and the constant was attempted to be constant evaluated. This caused the constant evaluator to ICE.
Add a special case for AnonConsts in rustc_hir_typeck, as suggested by @BoxyUwU in rust-lang/rust#137582. There is no checking for `#![feature(unsized_const_params)]` which should eventually revert this check when the feature becomes more implemented.
That issue is assigned to @el-ev but I started looking into this as a jumping off point / motivation to learn some compiler stuff, and I eventually got to the point of fixing it, so I'm submitting a PR anyway. So just a ping/FYI to @el-ev that I'm submitting this, sorry!
There are three relevant github issues to this ICE that I could find:
- fixesrust-lang/rust#137582
- fixesrust-lang/rust#151591
The similar issue rust-lang/rust#104685 is NOT fixed, it might be good to glance at that before verifying this particular fix, to make sure this fix is actually in the right place. (I haven't looked at it much)
r? @BoxyUwU
Check proj's parent is trait or not when checking dyn compatibility
Fixes https://github.com/rust-lang/rust/issues/151708
When checking dyn compatibility, `proj` here may point to free const whose parent is not trait. Then `TraitRef::from_assoc` will call `generics_of` on the wrong parent.
After this change, the following case without `#[type_const]` will still emit ICE same to https://github.com/rust-lang/rust/issues/149066, but different to the ICE reported in https://github.com/rust-lang/rust/issues/151708
```rust
#![feature(min_generic_const_args)]
// #[type_const]
const N: usize = 2;
trait CollectArray {
fn inner_array(&self) -> [i32; N];
}
```
r? @BoxyUwU
Forbid manual `Unpin` impls for structurally pinned types
Part of [`pin_ergonomics`](https://github.com/rust-lang/rust/issues/130494). It forbids to `impl Unpin for T` where `T` is an ADT marked with `#[pin_v2]`.
coverage: Add a test case for a previously-unknown span mismatch
- This is a revised version of https://github.com/rust-lang/rust/pull/152036.
---
In https://github.com/rust-lang/rust/pull/145643, a defensive check was added to detect spans that unexpectedly don't match the context of the function body span. There was no known way to trigger that condition, so a `debug_assert!` was added to make violations easier to notice.
A way to trigger the condition using nested macro expansions was subsequently found and reported as an ICE (in debug-assertion builds) in https://github.com/rust-lang/rust/issues/147339.
Now that we have a concrete example to investigate, we can remove the `debug_assert!` so that there is no ICE in debug-assertion builds.
- Fixes https://github.com/rust-lang/rust/issues/147339.
r? chenyukang
The `vldap1` and `vstl1` RCPC3 intrinsics introduced in standard library unconditionally use `AtomicI64`. This breaks builds on target that do not support 64-bit atomics, such as `aarch64-unknown-none` with `max-atomic-width` set to 0. This commit adds a `#[cfg(target_has_atomic = "64")]` guard to these intrinsics
In #20327 we started truncating custom check commands so they render
nicely in the IDE. This was then accidentally undone in
9c18569d0c87d7f643db50b4806b59642762f1c3, and ended up making the
command summary longer (it included full paths).
We ended up with a `Display` implementation and a `display_command`
function that both tried to solve the same problem. I've merged and
simplified the logic and added tests.
This addresses the need for clarification brought up in an issue.
Specifically, it notes that some implementations may choose to panic if
they detect deadlock situations during recursive locking attempts for
both `read()` and `write()` calls.
* Provide an example highlighting that multiple read locks can be
held across different threads simultaneously.
* Remove the example that shows a situation that can potentially deadlock.
(as demonstrated in the very same documentation a few paragraphs
above)
* Improve documentation regarding the possibility of panics during
recursive read or write lock attempts.
Issues: Ambiguity in RwLock documentation about multiple read() calls...
Signed-off-by: Henner Zeller <h.zeller@acm.org>
Use the query vtable in `query_feed` plumbing
The `query_feed` function needs to be able to do two important things with (erased) query values: hash them, and debug-print them.
Both of those are things that the query's vtable already knows how to do. So by passing in a vtable to `query_feed`, we can give it a nicer signature, avoid having to unerase values in the function itself, and clean up some caller-side code as well.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#152008 (`rust-analyzer` subtree update)
- rust-lang/rust#151109 (fN::BITS constants for feature float_bits_const)
- rust-lang/rust#151976 (Rename `collect_active_jobs` to several distinct names)
- rust-lang/rust#151691 (compiletest: Don't assume `aux-crate` becomes a `*.so` with `no-prefer-dynamic`)
- rust-lang/rust#151919 (fix: Make `--color always` always print color with `--explain`)
- rust-lang/rust#152017 (Remove `with_no_trimmed_paths` use in query macro)
- rust-lang/rust#152028 (Convert to inline diagnostics in `rustc_driver_impl`)
Convert to inline diagnostics in `rustc_driver_impl`
Converts a crate for rust-lang/rust#151366
This PR is almost completely autogenerated by a hacky script I have locally :)
Remove `with_no_trimmed_paths` use in query macro
We already use `with_no_trimmed_paths!` when calling query descriptors so the extra call generated by the macro is not needed.
fix: Make `--color always` always print color with `--explain`
Fixesrust-lang/rust#151643.
This changes the behaviour of `handle_explain` in `rustc_driver_impl` to always output color when the `--color always` flag is set.
r? @tgross35
compiletest: Don't assume `aux-crate` becomes a `*.so` with `no-prefer-dynamic`
Since it does not make sense to do so. If someone prefers no dynamic stuff, the last thing they want to look for is an .so file. Also add a regression test. Without the fix, the test fails with:
error: test compilation failed although it shouldn't!
--- stderr -------------------------------
error: extern location for no_prefer_dynamic_lib does not exist: .../auxiliary/libno_prefer_dynamic_lib.so
--> .../no-prefer-dynamic-means-no-so.rs:9:5
|
LL | no_prefer_dynamic_lib::return_42();
| ^^^^^^^^^^^^^^^^^^^^^
### Needed by:
- https://github.com/rust-lang/rust/pull/150591 because of https://github.com/rust-lang/rust/issues/151271. But IMHO this PR makes sense on its own.
### Must wait for:
- [x] https://github.com/rust-lang/rust/pull/151695
Rename `collect_active_jobs` to several distinct names
Key renames:
- Function `collect_active_jobs` → `collect_active_jobs_from_all_queries` (method in trait `QueryContext`)
- Constant `COLLECT_ACTIVE_JOBS` → `PER_QUERY_GATHER_ACTIVE_JOBS_FNS` (list of per-query function pointers)
- Function `collect_active_jobs` → `gather_active_jobs` (per-query function in `query_impl::$name`)
- Function `collect_active_jobs` → `gather_active_jobs_inner` (method in `QueryState`)
- Giving these four things distinct names makes it a lot easier to tell them apart!
- The switch from “collect” (all queries) to “gather” (single query) is intended to make the different parts a bit more memorable and searchable; I couldn't think of a more natural way to express this distinction so I settled for two different synonyms.
There should be no change to compiler behaviour.
r? nnethercote (or compiler)
fN::BITS constants for feature float_bits_const
Also enables the feature for compiler_builtins as otherwise this causes a warning and conflicts with the Float extension trait.
---
Implementation for rust-lang/rust#151073
Feature flag: `#![feature(float_bits_const)]`
Note that this is likely to conflict with some extension traits, as it has with compiler builtins. However, assuming correct values for the constants, they are either `u32`, the same type, which should not cause a problem (as shown by enabling the feature for compiler_builtins), or a different type (e.g. `usize`), which should cause a compiler error. Either way this should never change behaviour unless the extension trait implemented an incorrect value.
Also note that it doesn't seem to be possible to put multiple unstable attributes on an item, so `f128::BITS` and `f16::BITS` are gated behind the feature flags for those primitives, rather than `#![feature(float_bits_const)]`
Example
---
```rust
fn foo(cond: bool) {
if cond.$0
}
```
**Before this PR**
```text
...
sn deref *expr
sn ref &expr
...
```
**After this PR**
```text
...
sn deref *expr
sn not !expr
sn ref &expr
...
```
Since it does not make sense to do so. If someone prefers no dynamic
stuff, the last thing they want to look for is an `.so` file. Also add a
regression test. Without the fix, the test fails with:
error: test compilation failed although it shouldn't!
--- stderr -------------------------------
error: extern location for no_prefer_dynamic_lib does not exist: .../auxiliary/libno_prefer_dynamic_lib.so
--> .../no-prefer-dynamic-means-no-so.rs:9:5
|
LL | no_prefer_dynamic_lib::return_42();
| ^^^^^^^^^^^^^^^^^^^^^
The usage of normal `display()` caused it to emit `{unknown}` which then failed to parse in `make::ty()`.
Really we should not use stringly-typed things here, but that's a change for another day.
Fix missing unused_variables lint when using a match guard
Within a binding pattern match guard, only real reads of a bound local impact its liveness analysis - not the fake read that is injected.
Fixesrust-lang/rust#151983
r? compiler
Work around rustfmt giving up on a large expression
- https://github.com/rust-lang/rustfmt/issues/3863
---
In some cases, if rustfmt sees a string literal that is too long for it to comfortably format, it will give up on formatting the entire enclosing expression.
For complex builder expressions, that will prevent auto-formatting for frustratingly large sections of code.
This PR works around a particular occurrence of that phenomenon in `compiler/rustc_interface/src/util.rs`, by splitting a single error message string across multiple lines. This allows rustfmt to successfully auto-format the entire enclosing expression, which is dozens of lines long.
There should be no change to compiler behaviour.
Add codegen test for SLP vectorization
close: rust-lang/rust#142519
This PR adds a codegen regression test for rust-lang/rust#142519. A regression in LLVM to fail to auto-vectorize, leading to significant performance loss.
The SLP vectorizer correctly groups the 4-byte operations into <4 x i8> vectors.
The loop state is maintained in SIMD registers (phi <4 x i8>).
The test remains robust across architectures (AArch64 vs x86_64) by allowing flexible store types (i32 or <4 x i8>).
Move bigint helper tracking issues
Closesrust-lang/rust#85532.
This splits the remainder of the `bigint_helper_methods` tracking issue into three issues:
* `signed_bigint_helpers`: rust-lang/rust#151989
* `widening_mul`: rust-lang/rust#152016
* `const_unsigned_bigint_helpers`: rust-lang/rust#152015
Note that the existing stable methods were merged under the `unsigned_bigint_helpers` feature as part of rust-lang/rust#144494.
Move the `fingerprint_style` special case into `DepKindVTable` creation
I'm a little bit fuzzy on *precisely* why anonymous queries are treated as having `FingerprintStyle::Opaque`, but I'm pretty confident that baking this special case into the query vtable is equivalent to the current behaviour, while being marginally more efficient.
(I believe this special case comes from anonymous queries not having a fingerprint in the first place, so “opaque” is just there to signal that reconstructing a key is impossible.)
Codegen tests for Arm Cortex-R82
This PR adds checks to the `aarch64v8r-unknown-none` target to verify that if the Cortex-R82 CPU is enabled (with `-Ctarget-cpu=cortex-r82`), that the appropriate additional AArch64 features are enabled.
This is important because Cortex-R82 is (currently) the only processor implementing Armv8-R AArch64 and it implements a number of Armv8 features over and above the baseline for the architecture. Many of these features are of interest to safety-critical firmware development (for example `FEAT_RASv1p1`, which adds support for the *RAS Common Fault Injection Model Extension*) and so we anticipate them being enabled when building such firmware.
We are offering these tests upstream in-lieu of a full Cortex-R82 specific target because we understand the Project has a preference for architecture-baseline targets over CPU-specific targets.
~~This PR builds on and requires https://github.com/rust-lang/rust/pull/150863, but we've pulled them out as a separate PR.~~ That PR has been merged.
## Ownership
This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
We only run LLDB 1500 in CI. Any test with a min-lldb-version above that
is currently ignored. It's not clear any of these tests actually work
with that LLDB version, and they definitely don't work on LLDB ~2100.
So, ignore them until we fix debuginfo testing.
This has the nice side-effect of eliminating `rustc_codegen_ssa`'s
dependency on `rustc_query_system`. (Indeed, looking through such
dependencies was how I found this.)
PR #18043 changed flycheck to be scoped to the relevant package. This
broke projects using check commands that invoke rustc directly,
because diagnostic JSON from rustc doesn't contain the package ID.
This was visible in the rust-analyzer logs when RA_LOG is set to
`rust_analyzer::flycheck=trace`.
Before:
2026-02-02T07:03:48.020184937-08:00 TRACE diagnostic received flycheck_id=0 mismatched types package_id=None scope=Workspace
...
2026-02-02T07:03:55.082046488-08:00 TRACE clearing diagnostics flycheck_id=0 scope=Workspace
After:
2026-02-02T07:14:32.760707785-08:00 TRACE diagnostic received flycheck_id=0 mismatched types package_id=None scope=Package { package: BuildInfo { label: "fbcode//rust_devx/rust-guess-deps:rust-guess-deps" }, workspace_deps: Some({}) }
...
2026-02-02T07:14:48.355981415-08:00 TRACE clearing diagnostics flycheck_id=0 scope=Package { package: BuildInfo { label: "fbcode//rust_devx/rust-guess-deps:rust-guess-deps" }, workspace_deps: Some({}) }
Previously r-a assumed that a diagnostic without a package ID applied
to the whole workspace. We would insert the diagnostic at the
workspace level, but then only clear diagnostics for the package.
As a result, red squiggles would get 'stuck'. Users who had fixed
compilation issues would still see the old red squiggles until they
introduced a new compilation error.
Instead, always apply diagnostics to the current package if flycheck
is scoped to a package and the diagnostic doesn't specify a
package. This makes CargoCheckEvent(None) and CargoCheckEvent(Some(_))
more consistent, as they now both match on scope.
Fix uninitialized UEFI globals in tests
Export globals via a `doc(hidden)` module. In test code, use the globals from `realstd` so that they are properly initialized.
CC @Ayush1325
Use `#![feature(adt_const_params)]` for static query flags
As suggested by https://github.com/rust-lang/rust/pull/151633#issuecomment-3799180811, this replaces multiple clunky const booleans with a single const struct, which is a bit nicer.
This should also make it easier to experiment with statically resolving other flags, like `eval_always`.
There are currently no other compiler crates using `feature(adt_const_params)`, so hopefully it's mature enough for a simple use-case like this one.
compiletest: Support `--extern` modifiers with `proc-macro` directive
So that the `src/tools/compiletest/src/directives/auxiliary/tests.rs` test does not have to (ab)use the `aux-crate` directive for this purpose.
This is very edge-casey so I don't think we should document this in rustc-dev-guide. Mentioning it will confuse more than it helps. If someone needs to do this they will look at the code and easily find the functionality.
This is a bit hacky since `--extern priv:pm.rs` is not valid, but we can make our directives work however we want. And I think this is a fine pragmatic approach. Doing it "the right way" would be a lot of work for not much gain. Plus, that work can be done incrementally in small steps in the future if wanted.
r? @Zalathar
---
Follow-up to:
- https://github.com/rust-lang/rust/pull/151353
- https://github.com/rust-lang/rust/pull/151670
### Unblocks:
- https://github.com/rust-lang/rust/pull/151691, because without this fix that test fails (see https://github.com/rust-lang/rust/pull/151691#issuecomment-3800315302)
resolve: Report more visibility-related early resolution ambiguities for imports
The new ambiguities are reported when the import's visibility is ambiguous and may depend on the resolution/expansion order.
Detailed description: https://github.com/rust-lang/rust/pull/149596#issuecomment-3620449013.
CargoCheckMessage and CargoCheckParser were misleading, because they
could apply to any tool that emits diagnostics. For example, it may be
rustc directly rather than via cargo.
Clarify this in the names. This is most noticeable when working on
custom check commands in rust-project.json.
Now, only `call_span` is replaced, so the receiver is not a part of the
diff. This also removes the need to create a snippet for the receiver.
changelog: [`str_split`]: reduce suggestion diff
The [`allow_attributes`] lint false-negatived (failed to trigger) on
attributes that contained internal whitespace, such as `#[ allow (
dead_code ) ]`.
This happened because `clippy_utils::is_from_proc_macro` relied on
strict string matching (e.g., expecting exactly `#[allow`), which fails
if there are spaces.
#### Solution:
I have updated `clippy_utils::is_from_proc_macro` to support flexible
whitespace matching.
1. Added `Pat::Attr(Symbol)`.
2. Updated `span_matches_pat` to strip `#[` and trim validation
whitespace before checking the name.
Verified with a new test case in `tests/ui/allow_attributes.rs`.
Fixesrust-lang/rust-clippy#16491
----
changelog: [`allow_attributes`]: correctly detect attributes with
internal whitespace
This fixes an FP in `doc_paragraphs_missing_punctuation` which prevented
having lists (and code blocks) as parts of sentences. Even though it was
often possible to rephrase to make the lint happy, it likely makes the
lint more acceptable if we just allow these (at the risk of some false
negatives).
This fix might be a bit ad hoc, but it should make the exception pretty
explicit and easy to follow.
- Fixesrust-lang/rust-clippy#16370
changelog: [`doc_paragraphs_missing_punctuation`]: allow unpunctuated
paragraphs before lists and code blocks
---
Feel free to push to this branch as needed.
Various `QueryStackFrame` variables are called `query`; `frame` is a
better name. And various `QueryInfo` variables are called `frame`;
`info` is a better name.
This eliminates some confusing `query.query()` occurrences, which is a
good sign, and some `frame.query` occurrences become `info.frame`.
Include assoc const projections in CFI trait object
Fixesrust-lang/rust#151878
After https://github.com/rust-lang/rust/pull/150843, projections of trait objects should include assoc consts, but the cfi `trait_object_ty` still include only assoc types. So that we got the ICE `expected 1 projection but got 0`.
Update hexagon target linker configurations
* hexagon-unknown-qurt: Use hexagon-clang from Hexagon SDK instead of rust-lld
* hexagon-unknown-linux-musl: Use hexagon-unknown-linux-musl-clang from the open source toolchain instead of rust-lld.
* hexagon-unknown-none-elf: Keep rust-lld but fix the linker flavor.
rust-lld is appropriate for a baremetal target but for traditional programs that depend on libc, using clang's driver makes the most sense.
Add regression test for issue #138225
Adds a regression test for rust-lang#138225.
The compiler used to ICE with `ReferencesError` when compiling code with:
- An undefined type in a struct field
- An async function returning a static reference to that struct
- Optimizations enabled (`-C opt-level=1` or higher)
The bug has been fixed and now correctly reports `E0425: cannot find type`.
Test file: `tests/ui/async-await/ice-static-in-async-fn-issue-138225.rs`
Closesrust-lang/rust#138225
Tweak `VecCache` to improve performance
This has some tweaks to `VecCache` to improve performance.
- It saves a `compare_exchange` in `complete` using the new `put_unique` function.
- It removes bound checks on entries. These are instead checked in the `slot_index_exhaustive` test.
- `initialize_bucket` is outlined and tuned for that.
cc @Mark-Simulacrum
On type errors where the difference is expecting an owned type and getting a reference, if the expression is a `.clone()` call and the type is annotated with `#[derive(Clone)]`, we now explain implicit bounds and suggest manually implementing `Clone`.
```
error[E0308]: mismatched types
--> $DIR/derive-implicit-bound-on-clone.rs:10:5
|
LL | fn clone_me<T, K>(x: &ContainsRc<T, K>) -> ContainsRc<T, K> {
| ---------------- expected `ContainsRc<T, K>` because of return type
LL | x.clone()
| ^^^^^^^^^ expected `ContainsRc<T, K>`, found `&ContainsRc<T, K>`
|
= note: expected struct `ContainsRc<_, _>`
found reference `&ContainsRc<_, _>`
note: `ContainsRc<T, K>` does not implement `Clone`, so `&ContainsRc<T, K>` was cloned instead
--> $DIR/derive-implicit-bound-on-clone.rs:10:5
|
LL | x.clone()
| ^
help: `Clone` is not implemented because the some trait bounds could not be satisfied
--> $DIR/derive-implicit-bound-on-clone.rs:5:19
|
LL | #[derive(Clone)]
| ----- in this derive macro expansion
LL | struct ContainsRc<T, K> {
| ^ ^ derive introduces an implicit unsatisfied trait bound `K: Clone`
| |
| derive introduces an implicit unsatisfied trait bound `T: Clone`
= help: consider manually implementing `Clone` to avoid the implict type parameter bounds
```
```
note: required for `B<C>` to implement `Copy`
--> $DIR/deriving-copyclone.rs:9:10
|
LL | #[derive(Copy, Clone)]
| ^^^^ unsatisfied trait bound introduced in this `derive` macro
LL | struct B<T> {
| - would need to be `Copy`
```
When encountering a bound coming from a derive macro, suggest manual impl of the trait.
Use the span for the specific param when adding bounds in builtin derive macros, so the diagnostic will point at them as well as the derive macro itself.
```
error[E0277]: can't compare `SomeNode` with `SomeNode`
--> f29.rs:24:15
|
24 | accept_eq(&node);
| --------- ^^^^^ no implementation for `SomeNode == SomeNode`
| |
| required by a bound introduced by this call
|
= note: -Ztrack-diagnostics: created at compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs:279:39
= help: the trait `PartialEq` is not implemented for `SomeNode`
note: required for `Id<SomeNode>` to implement `PartialEq`
--> f29.rs:3:10
|
3 | #[derive(PartialEq, Eq)]
| ^^^^^^^^^ unsatisfied trait bound introduced in this `derive` macro
4 | pub struct Id<T>(PhantomData<T>);
| -
= help: consider manually implementing `PartialEq` to avoid undesired bounds
note: required by a bound in `accept_eq`
--> f29.rs:15:23
|
15 | fn accept_eq(_: &impl PartialEq) { }
| ^^^^^^^^^ required by this bound in `accept_eq`
help: consider annotating `SomeNode` with `#[derive(PartialEq)]`
|
13 + #[derive(PartialEq)]
14 | struct SomeNode();
|
```
When encountering a value that has a borrow checker error where the type was previously moved, when suggesting cloning verify that it is not already being derived. If it is, explain why the `derive(Clone)` doesn't apply:
```
note: if `TypedAddress<T>` implemented `Clone`, you could clone the value
--> $DIR/derive-clone-implicit-bound.rs:6:1
|
LL | #[derive(Clone, Copy)]
| ----- derived `Clone` adds implicit bounds on type parameters
LL | pub struct TypedAddress<T>{
| ^^^^^^^^^^^^^^^^^^^^^^^^-^
| | |
| | introduces an implicit `T: Clone` bound
| consider manually implementing `Clone` for this type
...
LL | let old = self.return_value(offset);
| ------ you could clone this value
```
Add new `byte_value` and `char_value` methods to `proc_macro::Literal`
Part of https://github.com/rust-lang/rust/issues/136652.
It adds two more methods to get unescaped `u8` and `char` from `proc_macro::Literal`.
r? @Amanieu
Remove the `dep_node` argument from `try_mark_previous_green`
This removes the `dep_node` argument from `try_mark_previous_green`. I think this makes it clearer that it's unused without debug assertions.
Rename `QueryResult` to `ActiveKeyStatus`
Long ago, this enum was also used to hold the cached result of a query evaluation that had completed successfully, so its name made some sense.
Nowadays, successful query evaluation is represented by an entry in the query's in-memory cache, which is a separate data structure.
So this enum only deals with “active” query keys, i.e. those for which query evaluation has started, but has not yet completed successfully.
---
The split between jobs and results was introduced by:
- https://github.com/rust-lang/rust/pull/50102.
---
There should be no change to compiler behaviour.
typeck_root_def_id: improve doc comment
This was initially written to be exhaustive, but one more type that can only be type-checked with its containing item has since been added, and was not mentioned. So, make it future-proof by mentioning just the one example.
Also, a previous refactor left this less readable.
Closesrust-lang/rust-clippy#16484
changelog: [`unwrap_used`] fix FN when using fully qualified syntax
changelog: [`expect_used`] fix FN when using fully qualified syntax
This was initially written to be exhaustive, but one more type that can only be type-checked with its containing item has since been added, and was not mentioned. So, make it future-proof by mentioning just the one example.
Also, a previous refactor left this less readable.
Re-export `hashbrown::hash_table` from `rustc_data_structures`
We don't always re-export shared dependencies, but for `hashbrown::hash_table` I think it makes sense, for a few reasons:
- The lower-level `HashTable` type is already part of the public API of `rustc_data_structures` via the `ShardedHashMap` type alias, and other compiler crates currently depend on being able to access its internal hash tables.
- The `Cargo.toml` entry for `hashbrown` is non-trivial, making it harder to keep in sync and harder to move between crates as needed.
- [And we currently aren't using `[workspace.dependencies]` for various reasons.](https://github.com/rust-lang/rust/pull/146113)
- It's fine for other compiler crates to use `hash_table` specifically (with care), but they probably shouldn't be using the higher-level `hashbrown::HashMap` and `hashbrown::HashSet` types directly, because they should prefer the various map/set aliases defined by `rustc_data_structures`. Re-exporting only `hash_table` helps to discourage use of those other types.
There should be no change to compiler behaviour.
Feature-gate `mut ref` patterns in struct pattern field shorthand
Tracking issue for `mut_ref` (and other parts of Match Ergonomics 2024): https://github.com/rust-lang/rust/issues/123076https://github.com/rust-lang/rust/pull/123080 introduced `mut ref`[^1] patterns (for by-reference bindings where the binding itself is mutable), feature-gated behind the `mut_ref` feature, except for in struct pattern shorthand, where the feature gating was missing. Thus, `mut ref` patterns in struct pattern shorthand has been unintentionally stable for ~18 months (since 1.79.0 ([compiler explorer](https://rust.godbolt.org/z/4WTrvhboT))).
This PR adds feature-gating for `mut ref` patterns in struct pattern shorthand. Since this is reverting an accidental stabilization, this probably needs a crater run and a T-lang FCP?
Some alternative possibilities:
* Do nothing (let the inconsistency exist until `feature(mut_ref)` is stabilized)
* Document the existing behavior
* Do a FCW instead of fully feature-gating
* Stabilize `feature(mut_ref)`
CC https://github.com/rust-lang/rust/pull/123080#issuecomment-3746793632
CC @Nadrieril
[^1]: everything in this description also applies analogously to `mut ref mut` patterns.
GVN: Elide more intermediate transmutes
We already skipped intermediate steps like `u32` or `i32` that support any (initialized) value.
This extends that to also allow skipping intermediate steps whose values are a superset of either the source or destination type. Most importantly, that means that `usize` → `NonZeroUsize` → `ptr::Alignment` and `ptr::Alignment` → `NonZeroUsize` → `usize` can skip the middle because `NonZeroUsize` is a superset of `Alignment`.
Then `Alignment::as_usize` is updated to take advantage of that and let us remove some more locals in a few places.
r? cjgillot
Fix ICE when parsing frontmatter without newline
Fixesrust-lang/rust#151882
we can not add a normal test case for it:
- no newline at the end of file, we can bypass this with change test file name with `ignore-tidy`
- multiple errors in stderr, this conflicts with the previous bypass, seems we can not add multiple error annotations in one line
anyway, I added a `run-make` test for it.
Remove unused method `DroplessArena::contains_slice`
- This method was added for https://github.com/rust-lang/rust/pull/120128.
- It became unused in https://github.com/rust-lang/rust/pull/136593.
Checking whether a particular slice is within an arena is a bit of a sketchy operation, so if there's no pressing need for it then I think we're better off not having it lying around.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#151262 (Introducing clap on tidy)
- rust-lang/rust#151896 (Revert enabling `outline-atomics` on various platforms)
- rust-lang/rust#151849 (refactor: remove `Ty::pinned_ref` in favor of `Ty::maybe_pinned_ref`)
- rust-lang/rust#151892 (Document enum types used as values for E0423)
This commit introduces initial, unstable support for Unix domain sockets
(UDS) on Windows, behind the `windows_unix_domain_sockets` feature gate
Added types:
- `std::os::windows::net::SocketAddr`: represents a UDS address with support
for pathname addresses (abstract and unnamed are parsed but not yet fully
supported).
- `std::os::windows::net::UnixListener`: server-side UDS listener.
- `std::os::windows::net::UnixStream`: client/server stream for UDS.
Key features:
- Binding and connecting using filesystem paths.
- Basic I/O via `Read`/`Write`.
- Address querying (`local_addr`, `peer_addr`).
- Non-blocking mode, timeouts, and socket duplication.
- Includes basic test coverage for smoke, echo, path length, and bind reuse.
Document enum types used as values for E0423
### Problem
The E0423 error explanation did not include an example for enum types being used
as values, which is a common source of confusion for users.
For example, the following code:
```rust
fn main() {
let x = Option::<i32>;
}
```
refactor: remove `Ty::pinned_ref` in favor of `Ty::maybe_pinned_ref`
Also returns the `Region` of the reference type in `Ty::maybe_pinned_Ref`.
Part of rust-lang/rust#149130.
r? jackh726
Introducing clap on tidy
### Context
Currently tidy parses paths/flags from args_os manually, and the extraction is spreading multiple files. It may be a breeding ground for bugs.
ref: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/How.20--ci.3Dtrue.20interact.20with.20CiEnv.3F/near/543171560
(N.B. We've talked about introducing a ci flag in tidy in that thread, but I don't do it in this PR as I don't want to put multiple changes into a PR. I will introduce the flag in a coming PR.)
### Changes
This PR replaces current parsing logic with clap. To confirm the new parser works fine, I introduce an unit test for it.
### Build time
We've concerned about how clap increases the build time. In order to confirm the increment is acceptable, I did an experiment on CI:
- Run cargo build without cache for tidy 50 times in each environment on CI
- Calculate an average and a standard deviation from the result, and plot them
Here is the graph:
<img width="943" height="530" alt="rust_tidy_build_time" src="https://github.com/user-attachments/assets/c7deee69-9f38-4044-87dc-76d6e7384f76" />
- Clap tends to increase build time ~2s. We think this is not a big problem
- Build time differs in each environment
- In some cases standard deviation are high, I suppose that busyness of CI instances affect build time
The `fma:` label in dffma.s was being exported as a global symbol
causing a "symbol 'fma' is already defined" error when linking with
libm's `fma` function.
Unfortunately rust-lang/compiler-builtins#682 removed `.global fma` but
didn't address the implicit global export of the label itself.
--- old.txt 2026-01-30 20:31:37.265844316 -0600
+++ new.txt 2026-01-30 20:31:46.531950264 -0600
@@ -1,4 +1,3 @@
-00000000 t fma
00000000 T __hexagon_fmadf4
00000000 T __hexagon_fmadf5
00000000 T __qdsp_fmadf5
Remove duplicated code in `slice/index.rs`
Looks like `const fn` is far enough along now that we can just not have these two copies any more, and have one call the other.
I left a few, like
```rust
let result: Result<_, ModError<'_>> = try {
```
where it felt like seeing it might still be useful for the reader.
Feel free to push back on any of these changes if you think seeing the type would be better.
Easy to input other patterns, or bind variable in let-chain
Example
---
```rust
fn main() {
let bar = 2;
if bar.$0
}
```
**Before this PR**
No complete 'let'
**After this PR**
```rust
fn main() {
let bar = 2;
if let $1 = bar
}
```
resolve: Remove `force` parameter from `resolve_ident_in_scope`
`force == true` is used for turning `Determinacy::Undetermined` into `Determinacy::Determined` during error recovery.
It's only needed in two places:
- `resolve_macro_or_delegation_path` - the normal case
- `resolve_path_with_ribs` - obscure case, only when resolving visibilities and only for improving diagnostics in `tests\ui\resolve\visibility-indeterminate.rs`, I'm not actually sure if we should keep it
In other cases `Determinacy::Undetermined` is just ignored or can be propagated.
constify `Iterator`, take IV
Like its predecessors (rust-lang/rust#92433, rust-lang/rust#102225, rust-lang/rust#106541), this PR allows one to make `Iterator` implementations `const`, and thus enables the ability to have `for` loops in `const` contexts. I've also included constifying `Option as IntoIterator`, `option::IntoIter as Iterator` as a minimal dogfooding example.
But unlike its predecessors, it uses a new attribute (not unsound anymore!) that prevents any `Iterator` extension methods from being called. This is intentionally made minimal for an initial approval, the fun stuff like `.fold`, `Range as Iterator` could be done later.
cc @rust-lang/wg-const-eval, cc @oli-obk to review the compiler parts
cc rust-lang/rust#92476
This also takes the chance to move forward the job to Linux v6.19-rc7,
thus the previous workaround is not needed anymore.
Link: https://github.com/rust-lang/rust/pull/151534
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Disable append-elements.rs test with debug assertions
The IR is a bit different (in particular wrt naming) if debug-assertions-std is enabled. Peculiarly, the issue goes away if overflow-check-std is also enabled, which is why CI did not catch this.
r? @the8472
Remove redundant `IntoQueryParam` calls from query plumbing
In each of these contexts, the key must have already been converted by the caller, since otherwise it wouldn't have type `Cache::Key`.
There should be no change to compiler behaviour.
The IR is a bit different (in particular wrt naming) if
debug-assertions-std is enabled. Peculiarly, the issue goes away
if overflow-check-std is also enabled, which is why CI did not
catch this.
Fix flakyness issue with `tests/rustdoc-gui/globals.goml` test
Just realized that when the search input is wrong, sometime we don't even load the search index (which is logical). Since we want to check that the search index is loaded, turned the query into something that works.
r? ghost
Make some load-from-disk function pointers optional in query vtables
For queries that never incremental-cache to disk, we can represent that fact with None (i.e. a null function pointer) in their vtables, and avoid having to generate stub functions that do nothing.
(There is no decrease in vtable size; we just go from 3/8 padding bytes to 4/8 padding bytes.)
There should be no change to compiler output.
Fix missing syntax context in lifetime hygiene debug output
`-Zunpretty=expanded,hygiene` was not printing the syntax context for lifetimes. For example, two macro-generated lifetimes `'a` with different hygiene would both print as `/* 2538 */` instead of `/* 2538#0 */` and `/* 2538#1 */`, making it impossible to distinguish them.
This was fixed by changing `print_lifetime` to call `ann_post()` with the full `Ident`, matching how regular identifiers are handled in `print_ident`.
Closes: rust-lang/rust#151797
Document a safety condition for `TypedArena::alloc_raw_slice`
This method was marked safe in https://github.com/rust-lang/rust/pull/116224/commits/51edc219906f0973dd66b4b6ff5ff0ac857a4cc6, because there was no apparent reason for it to be unsafe.
However, I believe that `alloc_raw_slice` does actually impose a significant safety obligation on its caller, because the caller must ensure that each slot in the slice is properly initialized before the arena is dropped.
This is because the arena's Drop impl will unconditionally drop every storage slot that has been handed out, so it has no way to handle slots that were accidentally left uninitialized because a hypothetical caller of `alloc_raw_slice` panicked before initializing them.
Reduce generics use in the query system.
In rust-lang/rust#151203 I tried and failed to simplify `QueryStackFrame`. This is an alternative approach. There is no functional change, just tweaking of some names and types to make things clearer. Best reviewed one commit at a time.
r? @oli-obk
privacy: Fix privacy lints in RPITITs
Visit RPITITs and report `private_interfaces`, `private_bounds` and `exported_private_dependencies` in them (these are regular, non-deprecation lints).
New hard errors are not reported, https://github.com/rust-lang/rust/pull/146470 is for hard errors.
So this PR doesn't contain any breakage or language changes.
`QueryStackFrame<I>` is a generic type, and the `I` parameter leaks out
to many other related types. However, it only has two instantiations in
practice:
- `QueryStackFrame<QueryStackFrameExtra>`
- `QueryStackFrame<QueryStackDeferred<'tcx>>`
And most of the places that currently use `QueryStackFrame<I>` are
actually specific to one of the instantiations. This commit removes the
unneeded genericity.
The following types are only ever used with `QueryStackDeferred<'tcx>`:
- QueryMap
- QueryJobInfo
- QueryJob
- QueryWaiter
- QueryLatchInfo
- QueryLatch
- QueryState
- QueryResult
and their `<I>` parameter is changed to `<'tcx>`.
Also, the `QueryContext::QueryInfo` associated type is removed.
`CycleError<I>` and `QueryInfo<I>` are still generic over type, because
they are used with both instantiations.
This required also adding a `<'tcx>` parameter to the traits
`QueryDispatcher` and `QueryContext`, which is annoying but I can't see
how to avoid it.
Fix accidental type inference in array coercion
Fixesrust-lang/rust#136420.
If the expectation of array element is a type variable, we should avoid resolving it to the first element's type and wait until LUB coercion is completed.
We create a free type variable instead which is only used in this `CoerceMany`.
[`check_expr_match`](847e3ee6b0/compiler/rustc_hir_typeck/src/_match.rs (L72)) and [`check_expr_if`](847e3ee6b0/compiler/rustc_hir_typeck/src/expr.rs (L1329)) where `CoerceMany` is also used do the [same](847e3ee6b0/compiler/rustc_hir_typeck/src/expectation.rs (L50)).
### [FCP Proposal](https://github.com/rust-lang/rust/pull/140283#issuecomment-2933771068):
> Array expressions normally lub their element expressions' types to ensure that things like `[5, 5_u8]` work and don't result in type mismatches. When invoking a generic function `fn foo<T>(_: [T; N])` with an array expression, we end up with an infer var for the element type of the array in the signature. So when typecking the first array element we compare its type with the infer var and thus subsequently require all other elements to be the same type.
>
> This PR changes that to instead fall back to "not knowing" that the argument type is array of infer var, but just having an infer var for the entire argument. Thus we typeck the array expression normally, lubbing the element expressions, and then in the end comparing the array expression's type with the array of infer var type.
>
> Things like
>
> ```rust
> fn foo() {}
> fn bar() {}
> fn f<T>(_: [T; 2]) {}
>
> f([foo, bar]);
> ```
>
> and
>
> ```rust
> struct Foo;
> struct Bar;
> trait Trait {}
> impl Trait for Foo {}
> impl Trait for Bar {}
> fn f<T>(_: [T; 2]) {}
>
> f([&Foo, &Bar as &dyn Trait]);
> ```
### Remaining inconsistency with `if` and `match`(rust-lang/rust#145048):
The typeck of array always uses the element coercion target type as the expectation of element exprs while `if` and `match` use `NoExpectation` if the expected type is an infer var.
This causes that array doesn't support nested coercion.
```rust
fn foo() {}
fn bar() {}
fn main() {
let _ = [foo, if false { bar } else { foo }]; // type mismatch when trying to coerce `bar` into `foo` in if-then branch coercion.
}
```
But we can't simply change this behavior to be the same as `if` and `match` since [many code](https://github.com/rust-lang/rust/pull/140283#issuecomment-3190564399) depends on using the first element's type as expectation.
Use `Rustc` prefix for `rustc` attrs in `AttributeKind`
cc rust-lang/rust#131229
Most `rustc_...` attrs have their variants named `RustcAttrName`, but several do not. Rename these attributes for consistency.
r? @jdonszelmann
thread::scope: document how join interacts with TLS destructors
Fixes https://github.com/rust-lang/rust/issues/116237 by documenting the current behavior regarding thread-local destructors as intended. (I'm not stoked about this, but documenting it is better than leaving it unclear.)
This also adds documentation for explicit `join` calls (both for scoped and regular threads), saying that those *will* wait for TLS destructors. That reflects my understanding of the current implementation, which calls `join` on the native thread handle. Are we okay with guaranteeing that? I think we should, so people have at least some chance of implementing "wait for all destructors" manually. This fixes https://github.com/rust-lang/rust/issues/127571.
Cc @rust-lang/libs-api
Rename, clarify, and document code for "erasing" query values
In order to reduce compile times and code size for the compiler itself, the query system has a mechanism for “erasing” and ”restoring” query values in certain contexts. See https://github.com/rust-lang/rust/pull/109333 for the original implementation.
Unfortunately, the erasure system has very little documentation, and involves a dizzying assortment of similarly-named types, traits, and functions.
This PR therefore renames several parts of the erasure API and implementation to hopefully be clearer, and adds comments to better explain the purpose and mechanism behind value erasure.
Summary of renames:
- fn `erase` → `erase_val` (avoiding ambiguity with module `erase`)
- fn `restore` → `restore_val`
- type `Erase<T>` → `Erased<T>` (for actual erased values of `T`)
- trait `EraseType` → `Erasable` (for types that can be erased and restored)
- associated type `EraseType::Result` → `Erasable::Storage`
- implementation-detail struct `Erased<T>` → `ErasedData<Storage>`
There should be no change to compiler behaviour.
Suggest ignore returning value inside macro for unused_must_use lint
Fixesrust-lang/rust#151269
The first commit fix the original issue,
the second commit is a code refactoring in this lint.
`-Zunpretty=expanded,hygiene` was not printing the syntax context for
lifetimes. For example, two macro-generated lifetimes `'a` with different
hygiene would both print as `/* 2538 */` instead of `/* 2538#0 */` and
`/* 2538#1 */`, making it impossible to distinguish them.
This was fixed by changing `print_lifetime` to call `ann_post()` with
the full `Ident`, matching how regular identifiers are handled in
`print_ident`.
Cleanup of `#[derive(Diagnostic)]` attribute parsers
This PR does a lot of refactoring on the implementation of `#[derive(Diagnostic)]`. It should have no observable effect other than error messages for incorrect usage of the attributes. In general, I think the error messages got better.
This PR can be reviewed commit by commit, each commit passes the tests.
- [Convert parse_nested_meta to parse_args_with for #[diagnostic]](https://github.com/rust-lang/rust/pull/151657/changes/9e61014a8a0bb1f1d7911511c303a7ae2a9c2a7d)
Start parsing `#[diagnostic]` using `syn`'s `parse_args_with` function instead of `parse_nested_meta`. This improves error messages and prepares for the new syntax needed for https://github.com/rust-lang/rust/issues/151366 which cannot be parsed using `parse_args_with`.
- [Convert parse_nested_meta to parse_args_with for #[subdiagnostic]](https://github.com/rust-lang/rust/pull/151657/changes/5d21a21695d56b74ea249f269ee10195251008b7)
Same as above but for `#[subdiagnostic]`
- [Remove unused no_span option](https://github.com/rust-lang/rust/pull/151657/changes/0bf3f5d51cb853884240792818d81e70daec6ab7)
Removes the `no_span` option of `#[suggestion]`, which there were no tests for and which seems to have been unused. If needed again in the future, this can be re-added pretty easily, but I find that unlikely.
- [Remove HasFieldMap trait in favour of passing FieldMap directly](https://github.com/rust-lang/rust/pull/151657/changes/2e8347abf4147d2bffe4d7989a21b17ae04cdb57)
Removes the `HasFieldMap` trait, because I don't really see the point of having a trait "has a field map" if we can just pass the fieldmap itself instead.
r? @Kivooeo
(Thanks for reviewing my PRs so far :3)
fix(parser): Disallow CR in frontmatter
T-lang came back on the stabilization PR (rust-lang/rust#148051) asking for CR to be disallowed
to leave room for all stray CRs to be rejected in the future.
At that point, the test can remain but the implementation can be
removed.
If that plan does not go through, we'll need to re-evaluate
- whether this is more lint-like and should defer to the calling tool
that is managing the frontmatter
- how much Rust should treat the frontmatter as Rust and apply the same
grammar restrictions of "no stray CR" (like raw string literals)
Part of rust-lang/rust#136889
Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#150474 (Tidy: detect ui tests subdirectory changes so `tests/ui/README.md` stays in sync)
- rust-lang/rust#150572 (Improve move error diagnostic for `AsyncFn` closures)
- rust-lang/rust#151596 (Fix -Zmir-enable-passes to detect unregistered enum names in declare_passes macro)
- rust-lang/rust#151802 (Make `QueryDispatcher::Qcx` an associated type)
- rust-lang/rust#149110 (Implement `cast_slice` for raw pointer types)
- rust-lang/rust#151559 ([rustdoc] Add a marker to tell users that there are hidden (deprecated) items in the search results)
- rust-lang/rust#151665 (Fix contrast ratio for `Since` element in rustdoc dark theme)
- rust-lang/rust#151785 (Stabilize feature(push_mut))
- rust-lang/rust#151798 (Update `askama` to `0.15.3`)
- rust-lang/rust#151800 (Subscribe myself to translation diagnostics)
- rust-lang/rust#151804 (Document, sort, and tweak spellcheck entries in `typos.toml`)
- rust-lang/rust#151805 (Fix grammar in `env::current_exe()#Security`)
Currently some required arguments (like path of the root dir) are ordered, but it causes an user (mainly bootstrap) needs to remember the order. This commit introduces long arguments (e.g., --root-path) for required args.
Current tidy parses paths and options manually, and parsing is spreading multple files. This commit introduces a parser using clap to clean and centralize it.
[rustdoc] Add a marker to tell users that there are hidden (deprecated) items in the search results
Someone on mastodon rightfully pointed out that having a visual indication that some search results were hidden would be a good idea if the "hide deprecated items" setting is enabled. In particular if no results are displayed.
It looks like this:
<img width="861" height="228" alt="Screenshot From 2026-01-24 00-26-33" src="https://github.com/user-attachments/assets/93aeef11-a550-47dc-9c78-219ea4fd822c" />
r? @lolbinarycat
Make `QueryDispatcher::Qcx` an associated type
There's no reason to think that a query dispatcher/vtable would support multiple query-context types, and this simplifies some generic signature boilerplate.
---
- This is the planned change that was mentioned in https://github.com/rust-lang/rust/pull/151777#issuecomment-3810715635.
r? nnethercote
Improve move error diagnostic for `AsyncFn` closures
When an async closure captures a variable by move but is constrained to `AsyncFn` or `AsyncFnMut`, the error message now explains that the closure kind is the issue and points to the trait bound, similar to the existing diagnostic for `Fn`/`FnMut` closures.
**Before:**
```
error[E0507]: cannot move out of `foos` which is behind a shared reference
--> src/lib.rs:12:20
|
11 | async fn foo(foos: &mut [&mut Foo]) -> Result<(), ()> {
| ---- move occurs because `foos` has type...
12 | in_transaction(async || -> Result<(), ()> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ `foos` is moved here
13 | for foo in foos {
| ---- variable moved due to use in coroutine
```
**After:**
```
error[E0507]: cannot move out of `y`, a captured variable in an `AsyncFn` closure
--> src/lib.rs:9:10
|
LL | let y = vec![format!("World")];
| - captured outer variable
LL | call(async || {
| ^^^^^^^^ captured by this `AsyncFn` closure
...
help: `AsyncFn` and `AsyncFnMut` closures require captured values to be able
to be consumed multiple times, but `AsyncFnOnce` closures may consume
them only once
--> src/lib.rs:5:27
|
LL | fn call<F>(_: F) where F: AsyncFn() {}
| ^^^^^^^^^
```
Fixesrust-lang/rust#150174
Tidy: detect ui tests subdirectory changes so `tests/ui/README.md` stays in sync
close: rust-lang/rust#150399
There's an issue where `tests/ui/README.md` isn't updated whenever the ui subdirectory changes.
I've added subdirectory change detection to tidy ~~added a new mention to `triage.toml` to notify `tests/ui/README.md` to also be updated~~.
r? @Urgau
clean up checks for constant promotion of integer division/remainder operations
I found the old logic with matches on `Option`s returned by other matches to be kind of complicated, so I rewrote it with `let` chains. There should be no change in behavior.
Implement `set_output_kind` for Emscripten linker
This makes cdylibs compile to working Emscripten dynamic libraries without passing extra RUSTFLAGS. This was previously approved as rust-lang/rust#98358 but there were CI failures that I never got around to fixing.
cc @workingjubilee
Borrowck: Simplify SCC annotation computation, placeholder rewriting
This change backports some changes from the now abandoned rust-lang/rust#142623.
Notably, it simplifies the `PlaceholderReachability` `enum` by replacing the case when no placeholders were reached with a standard `Option::None`.
It also rewrites the API for `scc::Annotations` to be update-mut rather than a more Functional programming style. This showed some slight performance impact in early tests of the PR and definitely makes the implementation simpler.
This probably wants a perf run just for good measure.
r? @lcnr
compiler-builtins: Remove the no-f16-f128 feature
This option was used to gate `f16` and `f128` when support across backends and targets was inconsistent. We now have the rustc builtin cfg `target_has_reliable{f16,f128}` which has taken over this usecase. Remove no-f16-f128 since it is now unused and redundant.
Do not suggest `derive` if there is already an impl
This PR fixes an issue where the compiler would suggest adding `#[derive(Trait)]` even if the struct or enum already implements that trait manually.
Fixes [#146515](https://github.com/rust-lang/rust/issues/146515)
T-lang came back on the stabilization PR asking for CR to be disallowed
to leave room for all stray CRs to be rejected in the future.
At that point, the test can remain but the implementation can be
removed.
If that plan does not go through, we'll need to re-evaluate
- whether this is more lint-like and should defer to the calling tool
that is managing the frontmatter
- how much Rust should treat the frontmatter as Rust and apply the same
grammar restrictions of "no stray CR" (like raw string literals)
resolve: Replace `Macros20NormalizedIdent` with `IdentKey`
This is a continuation of https://github.com/rust-lang/rust/pull/150741 and https://github.com/rust-lang/rust/pull/150982 based on the ideas from https://github.com/rust-lang/rust/pull/151491#issuecomment-3784421866.
Before this PR `Macros20NormalizedIdent` was used as a key in various "identifier -> its resolution" maps in `rustc_resolve`.
`Macros20NormalizedIdent` is a newtype around `Ident` in which `SyntaxContext` (packed inside `Span`) is guaranteed to be normalized using `normalize_to_macros_2_0`.
This type is also used in a number of functions looking up identifiers in those maps.
`Macros20NormalizedIdent` still contains span locations, which are useless and ignored during hash map lookups and comparisons due to `Ident`'s special `PartialEq` and `Hash` impls.
This PR replaces `Macros20NormalizedIdent` with a new type called `IdentKey`, which contains only a symbol and a normalized unpacked syntax context. (E.g. `IdentKey` == `Macros20NormalizedIdent` minus span locations.)
So we avoid keeping additional data and doing some syntax context packing/unpacking.
Along with `IdentKey` you can often see `orig_ident_span: Span` being passed around.
This is an unnormalized span of the original `Ident` from which `IdentKey` was obtained.
It is not used in map keys, but it is used in a number of other scenarios:
- diagnostics
- edition checks
- `allow_unstable` checks
This is because `normalize_to_macros_2_0` normalization is lossy and the normalized spans / syntax contexts no longer contain parts of macro backtraces, while the original span contains everything.
When an async closure captures a variable by move but is constrained to
`AsyncFn` or `AsyncFnMut`, the error message now explains that the
closure kind is the issue and points to the trait bound, similar to the
existing diagnostic for `Fn`/`FnMut` closures.
Tweak `SlicePartialEq` to allow MIR-inlining the `compare_bytes` call
rust-lang/rust#150265 disabled this because it was a net perf win, but let's see if we can tweak the structure of this to allow more inlining on this side while still not MIR-inlining the loop when it's not just `memcmp` and thus hopefully preserving the perf win.
This should also allow MIR-inlining the length check, which was previously blocked, and thus might allow some obvious non-matches to optimize away as well.
Add FileCheck annotations to simplify_match.rs
Remove `skip-filecheck` and add FileCheck directives to verify that GVN propagates the constant `false` and eliminates the match entirely.
The test now verifies:
- The debug info shows `x` as `const false` (constant propagation)
- No `switchInt` remains (match elimination)
- The function body is just `return` (dead code elimination)
Part of rust-lang/rust#116971.
r? cjgillot
Add `extern crate core` to diagnostic tests
We do this to solve the `failed to resolve: you might be missing crate core` messages that were previously visible in the stderr.
We also split off `subdiagnostic-derive-2` from the main `subdiagnostic-derive`, because the error for this test is now generated post-expansion.
compiler: Rename several types/traits for per-query vtables
- Follow-up to https://github.com/rust-lang/rust/pull/151577
---
This is another round of renaming for some subtle types and traits used by the query system, to hopefully make them easier to understand.
Key renames:
- struct `DynamicQuery` → `QueryVTable` (the actual vtable-like structure)
- struct `DynamicQueries` → `PerQueryVTables` (holds a vtable for each query)
- trait `QueryConfig` → `QueryDispatcher`
- (used by generic functions in `rustc_query_system` to interact with query vtables)
- struct `DynamicConfig` → `SemiDynamicQueryDispatcher`
- (implements `QueryDispatcher` by combining a vtable with some compile-time boolean flags for improved perf)
- trait `QueryConfigRestored` → `UnerasedQueryDispatcher`
- (provides a `QueryDispatcher` while also remembering the query's unerased value type; allows some per-query code to be moved out of macros and into generic functions)
This was trickier than `DepKindVTable`, because there are more types and traits involved, and it's harder to come up with distinctive and useful names for all of them.
There should be no change to compiler behaviour.
r? Kivooeo (or compiler)
Add some clarifications and fixes for fmt syntax
This tries to clarify a few things regarding fmt syntax:
- The comment on `Parser::word` seems to be wrong, as that underscore-prefixed words are just fine. This was changed in https://github.com/rust-lang/rust/pull/66847.
- I struggled to follow the description of the width argument. It referred to a "second argument", but I don't know what second argument it is referring to (which is the first?). Either way, I rewrote the paragraph to try to be a little more explicit, and to use shorter sentences.
- The description of the precision argument wasn't really clear about the distinction of an Nth argument and a named argument. I added a sentence to try to emphasize the difference.
- `IDENTIFIER_OR_KEYWORD` was changed recently in https://github.com/rust-lang/reference/pull/2049 to include bare `_`. But fmt named arguments are not allowed to be a bare `_`.
offload: move (un)register lib into global_ctors
Right now we initialize the openmp/offload runtime before every single offload call, and tear it down directly afterwards.
What we should rather do is initialize it once in the binary startup code, and tear it down at the end of the binary execution. Here I implement these changes.
Together, our generated IR has a lot less usage of globals, which in turn simplifies the refactoring in https://github.com/rust-lang/rust/pull/150683, where I introduce a new variant of our offload intrinsic.
r? oli-obk
Support trait objects in type info reflection
Tracking issue: https://github.com/rust-lang/rust/issues/146922
Adds type_info support for trait object types by introducing a DynTrait variant
~~I can't seem to get it to work correctly with `dyn for<'a> Foo<'a>`, though it works fine for normal `dyn Foo` trait objects~~
r? @oli-obk
This makes cdylibs compile to working Emscripten dynamic libraries without passing extra
RUSTFLAGS. This was previously approved as PR 98358 but there were CI failures that I
never got around to fixing.
Remove `skip-filecheck` and add FileCheck directives to verify that GVN
propagates the constant `false` and eliminates the match entirely.
The test now verifies:
- The debug info shows `x` as `const false` (constant propagation)
- No `switchInt` remains (match elimination)
- The function body is just `return` (dead code elimination)
The `exported_private_dependencies` lint can fire on any mention of an
item from a private dependency, including mentions inside of `use`.
Therefore, `useless_attribute` should not fire on lint attributes
mentioning `exported_private_dependencies` attached to a `use`.
changelog: [`useless_attribute`]: fix false positive on
`exported_private_dependencies` lint attributes
PR rust-lang/rust-clippy#15645 was used as an example for preparing this
PR.
- PATHS_SEP is defined as global const since I will implement
split_paths in the future.
- Tested using OVMF using QEMU.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Rustc no longer depends on winapi. Only cg_clif, cg_gcc and rustfmt
still use it, none of which are libraries to compile against. And in
case of both cg_clif and cg_gcc it never ends up in an artifact we ship.
For cg_clif it only shows up when the jit mode is enabled, which is not
the case for the version we ship. For cg_gcc it is used by a test
executable, which isn't shipped either.
Don't try to evaluate const blocks during constant promotion
As of https://github.com/rust-lang/rust/pull/138499, trying to evaluate a const block in anything depended on by borrow-checking will result in a query cycle. Since that could happen in constant promotion, this PR adds a check for const blocks there to stop them from being evaluated.
Admittedly, this is a hack. See https://github.com/rust-lang/rust/issues/124328 for discussion of a more principled fix: removing cases like this from constant promotion altogether. To simplify the conditions under which promotion can occur, we probably shouldn't be implicitly promoting division or array indexing at all if possible. That would likely require a FCW and migration period, so I figure we may as well patch up the cycle now and simplify later.
Fixesrust-lang/rust#150464
I'll also lang-nominate this for visibility. I'm not sure there's much to discuss about this PR specifically, but it does represent a change in semantics. In Rust 1.87, the code below compiled. In Rust 1.88, it became a query cycle error. After this PR, it fails to borrow-check because the temporaries can no longer be promoted.
```rust
let (x, y, z);
// We only promote array indexing if the index is known to be in-bounds.
x = &([0][const { 0 }] & 0);
// We only promote integer division if the divisor is known not to be zero.
y = &(1 / const { 1 });
// Furthermore, if the divisor is `-1`, we only promote if the dividend is
// known not to be `int::MIN`.
z = &(const { 1 } / -1);
// The borrowed temporaries can't be promoted, so they were dropped at the ends
// of their respective statements.
(x, y, z);
```
std: move time implementations to `sys`
This is probably the most complex step of rust-lang/rust#117276 so far. Unfortunately, quite some of the internal time logic defined in the PAL is also used in other places like the filesystem code, so this isn't just a series of simple moves. I've left all that logic inside the PAL and only moved the actual `SystemTime`/`Instant` implementations.
While there are no functional changes, this PR also contains some slight code cleanups on Windows and Hermit, these are explained in the relevant commits.
For additional details see the individual commits, I've tried to make the messages as helpful as possible about what's going on.
- Adds vluti2 intrinsics
- Adds famin/famax intrinsics
- Adds vstl1(q) intrinsics
- Adds vldap1(q) intrinsics
- Excludes vldap1_lane_f64 as in testing it fails assert_intr. There seems to be some bad IR gen from rust.
- Adds vscale(q) intrinsics
- Adds new intrinsics to arm_intrinsics.json
- Had to be done manually as intrinsics are not yet on developer.arm.com
This PR adds checks to the `aarch64v8r-unknown-none` target to verify that if the Cortex-R82 CPU is enabled (with `-Ctarget-cpu=cortex-r82`), that the appropriate additional AArch64 features are enabled.
This is important because Cortex-R82 is (currently) the only processor implementing Armv8-R AArch64 and it implements a number of Armv8 features over and above the baseline for the architecture. Many of these features are of interest to safety-critical firmware development (for example `FEAT_RASv1p1`, which adds support for the *RAS Common Fault Injection Model Extension*) and so we anticipate them being enabled when building such firmware.
We are offering these tests upstream in-lieu of a full Cortex-R82 specific target because we understand the Project has a preference for architecture-baseline targets over CPU-specific targets.
This PR builds on and requires https://github.com/rust-lang/rust/pull/150863, but we've pulled them out as a separate PR.
This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
This simplifies the `PlaceholderReachability` `enum` by
replacing the case when no placeholders were reached with
a standard `Option::None`.
It also rewrites the API for `scc::Annotations` to be update-mut
rather than a more Functional programming style. This showed some slight
performance impact in early tests of the PR and definitely makes
the implementation simpler.
compiletest: Add `CompilerKind` to distinguish between rustc and rustdoc
This PR slightly improves `TestCx::make_compile_args` by using `CompilerKind` to explicitly distinguish between rustc and rustdoc.
The resulting code could still use more attention, but I think this is a good incremental improvement.
There *should* (hopefully) be no change to overall compiletest behaviour.
Last on the list: Hermit. Since I anticipate that Hermit will share the UNIX
implementation in the future, I've left `Timespec` in the PAL to maintain a
similar structure. Also, I noticed that some public `Instant` methods were
redefined on the internal `Instant`. But the networking code can just use the
public `Instant`, so I've removed them.
WASI and TEEOS share the UNIX implementation. Since `Timespec` lives in the
PAL, this means that the `#[path]` imports of `unix/time.rs` still remain for
these two, unfortunately. Maybe we'll solve that in the future by always
including the UNIX PAL for these remotely UNIXy platforms. But that's a story
for another time...
Now for UNIX: `Timespec` is also used for things like futex or `Condvar`
timeouts, so it stays in the PAL along with some related definitions.
Everything else is `SystemTime`- and `Instant`-specific, and is thus moved to
`sys::time`.
Windows has a similar problem as UEFI: some internals are also used for
implementing other things. Thus I've left everything except for the actual
`Instant` and `SystemTime` implementations inside the PAL.
I've also taken the liberty of improving the code clarity a bit: there were a
number of manual `SystemTime` conversions (including one that masked an `i64`
to 32-bits before casting to `u32`, yikes) that now just call `from_intervals`.
Also, defining a `PerformanceCounterInstant` just to convert it to a regular
`Instant` immediately doesn't really make sense to me. I've thus changed the
`perf_counter` module to contain only free functions that wrap system
functionality. The actual conversion now happens in `Instant::now`.
Next up: UEFI. Unfortunately the time conversion internals are also required by
the filesystem code, so I've left them in the PAL. The `Instant` internals
however are only used for the `Instant` implementation, so I've moved them to
`sys` (for now).
On SOLID, the conversion functions are also used to implement helpers for
timeout conversion, so these stay in the PAL. The `Instant` (µITRON) and
`SystemTime` (SOLID-specific) implementations are merged into one. While it was
nice to have the µITRON parts in a separate module, there really isn't a need
for this currently, as there is no other µITRON target. Let's not worry about
this until such a target gets added...
Note that I've extracted the `get_tim` call from `Instant` into a wrapper
function in the PAL to avoid the need to make the inner `Instant` field public
for use in the PAL.
Now that the `unsupported` module exists, we can use it for VEX. VEX actually
supports `Instant` though, so the implementation-select needs to combine that
with the `unsupported` module.
Let's start with the easy ones:
* Motor just reexports its platform library
* The SGX code is just a trivial move
* Trusty, WASM and ZKVM are unsupported, this is very trivial. And we can get
rid of some `#[path = ...]`s, yay!
150265 disabled this because it was a net perf win, but let's see if we can tweak the structure of this to allow more inlining on this side while still not MIR-inlining the loop when it's not just `memcmp`.
This should also allow MIR-inlining the length check, which was previously blocked.
Use an associated type default for `Key::Cache`.
They currently aren't used because r-a didn't support them, but r-a support was recently merged in
https://github.com/rust-lang/rust-analyzer/pull/21243.
r? @Noratrieb
Reintroduce `QueryStackFrame` split.
I tried removing it in rust-lang/rust#151203, to replace it with something simpler. But a couple of fuzzing failures have come up and I don't have a clear picture on how to fix them. So I'm reverting the main part of rust-lang/rust#151203.
This commit also adds the two fuzzing tests.
Fixesrust-lang/rust#151226, rust-lang/rust#151358.
r? @oli-obk
slice/ascii: Optimize `eq_ignore_ascii_case` with auto-vectorization
- Refactor the current functionality into a helper function
- Use `as_chunks` to encourage auto-vectorization in the optimized chunk processing function
- Add a codegen test checking for vectorization and no panicking
- Add benches for `eq_ignore_ascii_case`
---
The optimized function is initially only enabled for x86_64 which has `sse2` as part of its baseline, but none of the code is platform specific. Other platforms with SIMD instructions may also benefit from this implementation.
Performance improvements only manifest for slices of 16 bytes or longer, so the optimized path is gated behind a length check for greater than or equal to 16.
Benchmarks - Cases below 16 bytes are unaffected, cases above all show sizeable improvements.
```
before:
str::eq_ignore_ascii_case::bench_large_str_eq 4942.30ns/iter +/- 48.20
str::eq_ignore_ascii_case::bench_medium_str_eq 632.01ns/iter +/- 16.87
str::eq_ignore_ascii_case::bench_str_17_bytes_eq 16.28ns/iter +/- 0.45
str::eq_ignore_ascii_case::bench_str_31_bytes_eq 35.23ns/iter +/- 2.28
str::eq_ignore_ascii_case::bench_str_of_8_bytes_eq 7.56ns/iter +/- 0.22
str::eq_ignore_ascii_case::bench_str_under_8_bytes_eq 2.64ns/iter +/- 0.06
after:
str::eq_ignore_ascii_case::bench_large_str_eq 611.63ns/iter +/- 28.29
str::eq_ignore_ascii_case::bench_medium_str_eq 77.10ns/iter +/- 19.76
str::eq_ignore_ascii_case::bench_str_17_bytes_eq 3.49ns/iter +/- 0.39
str::eq_ignore_ascii_case::bench_str_31_bytes_eq 3.50ns/iter +/- 0.27
str::eq_ignore_ascii_case::bench_str_of_8_bytes_eq 7.27ns/iter +/- 0.09
str::eq_ignore_ascii_case::bench_str_under_8_bytes_eq 2.60ns/iter +/- 0.05
```
Try to reduce rustdoc GUI tests flakyness
Should help with https://github.com/rust-lang/rust/issues/93784.
I replaced a use of `puppeteer.wait` function with a loop instead (like the rest of `browser-ui-test`).
r? @jieyouxu
Fix broken Xtensa installation link
### Location (URL)
https://doc.rust-lang.org/rustc/platform-support/xtensa.html
<img width="800" alt="image" src="https://github.com/user-attachments/assets/dbf1fea5-e65f-4bb2-beea-bf3267b12aff" />
### Summary
The Xtensa platform documentation currently links to an outdated Rust on ESP Book installation page that no longer exists.
The Rust on ESP Book has been reorganized, and the installation instructions previously referenced under `/book/installation/` are now located under the Getting Started section.
The link is updated to reference the current Toolchain Installation page, which contains the up-to-date instructions for building Xtensa targets.
lint: Use rustc_apfloat for `overflowing_literals`, add f16 and f128
Switch to parsing float literals for overflow checks using `rustc_apfloat` rather than host floats. This avoids small variations in platform support and makes it possible to start checking `f16` and `f128` as well.
Using APFloat matches what we try to do elsewhere to avoid platform inconsistencies.
remove `#[deprecated]` from unstable & internal `SipHasher13` and `24` types
These types are unstable and `doc(hidden)` (under the internal feature `hashmap_internals`). Deprecating them only adds noise (`#[allow(deprecated)]`) to all places where they are used, so this PR removes the deprecation attributes from them.
It also includes a few other small cleanups in separate commits, including one I overlooked in rust-lang/rust#151228.
Don't expose redundant information in `rustc_public`'s `LayoutShape`
Enum variant layouts don't need to store a full `LayoutShape`; just storing the fields offsets is enough and all other information can be inferred from the parent layout:
- size, align and ABI don't make much sense for individual variants and should generally be taken from the parent layout instead;
- variants always have `fields: FieldsShape::Arbitrary { .. }` and `variant: VariantShape::Single { .. }`.
In principle, the same refactor could be done on `rustc_abi::Layout` (see [this comment](https://github.com/rust-lang/rust/issues/113988#issuecomment-1646982272)) but I prefer starting with this smaller change first.
Adds two new Tier 3 targets - `aarch64v8r-unknown-none{,-softfloat}`
## New Tier 3 targets - `aarch64v8r-unknown-none` and `aarch64v8r-unknown-none-softfloat`
This PR adds two new Tier 3 targets - `aarch64v8r-unknown-none` and `aarch64v8r-unknown-none-softfloat`.
The existing `aarch64-unknown-none` target assumes Armv8.0-A as a baseline. However, Arm recently released the Arm Cortex-R82 processor which is the first to implement the Armv8-R AArch64 mode architecture. This architecture is similar to Armv8-A AArch64, however it has a different set of mandatory features, and is based off of Armv8.4. It is largely unrelated to the existing Armv8-R architecture target (`armv8r-none-eabihf`), which only operates in AArch32 mode.
The second `aarch64v8r-unknown-none-softfloat` target allows for possible Armv8-R AArch64 CPUs with no FPU, or for use-cases where FPU register stacking is not desired. As with the existing `aarch64-unknown-none` target we have coupled FPU support and Neon support together - there is no 'has FPU but does not have NEON' target proposed even though the architecture technically allows for it.
These targets are in support of firmware development on upcoming systems using the Arm Cortex-R82, particularly safety-critical firmware development. For now, it can be tested using the Arm's Armv8-R AArch64 Fixed Virtual Platform emulator, which we have used to test this target. We are also in the process of testing this target with the full compiler test suite as part of Ferrocene, in the same way we test `aarch64-unknown-none` to a safety-qualified standard. We have not identified any issues as yet, but if we do, we will send the fixes upstream to you.
## Ownership
This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
## Tier 3 Policy Notes
To cover off the Tier 3 requirements:
> A tier 3 target must have a designated developer or developers
Arm will maintain this target, and I have presumed the Embedded Devices Working Group will also take an interest, as they maintain the existing Arm bare-metal targets.
> Targets must use naming consistent with any existing targets
We prefix this target with `aarch64` because it generates A64 machine code (like `arm*` generates A32 and `thumb*` generates T32). In an ideal world I'd get to rename the existing target `aarch64v8a-unknown-none` but that's basically impossible at this point. You can assume `v6` for any `arm*` target where unspecified, and you can assume `v8a` for any `aarch64*` target where not specified.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
It works just like the existing AArch64 bare-metal target.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
Noted.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate.
It's a bare-metal target, offering libcore and liballoc.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible.
Done
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target.
AArch64 is a Tier 1 architecture, so I don't expect this target to cause any issues.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
Noted.
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.
It's AArch64 and so works with LLVM.
Update backtrace and windows-bindgen
Supersedes the backtrace bump in rust-lang/rust#151659
This is mostly just renaming `windows_targets` to `windows_link` but it needs to be done in tandem with the backtrace submodule update. The reason for doing this is that backtrace is both copy/pasted into std (via being a submodule) and published as an independent crate.
checksum-freshness: Fix invalid checksum calculation for binary files
Admittedly this is not the cleanest way to achieve this, but SourceMap is quite intertwined with source files being represented as Strings.
Tracking issue: https://github.com/rust-lang/cargo/issues/14136Closes: rust-lang/rust#151090
Stabilize ppc inline assembly
This stabilizes inline assembly for PowerPC and PowerPC64.
Corresponding reference PR: rust-lang/reference#2056
---
From the requirements of stabilization mentioned in https://github.com/rust-lang/rust/issues/93335
> Each architecture needs to be reviewed before stabilization:
> * It must have clobber_abi.
Done in https://github.com/rust-lang/rust/pull/146949.
> * It must be possible to clobber every register that is normally clobbered by a function call.
Done in https://github.com/rust-lang/rust/pull/131341
Similarly, `preserves_flags` is also implemented by this PR. Likewise, there is a non-code change to `preserve_flags` expectations that floating point and vector status and sticky bits are preserved. The reference manual update has more details.
> * Generally review that the exposed register classes make sense.
The followings can be used as input/output:
* reg (`r0`, `r[3-12]`, `r[14-r28]`): Any usable general-purpose register
* reg_nonzero (`r[3-12]`, `r[14-r28]`): General-purpose registers, but excludes `r0`. This is needed for instructions which define `r0` to be the value 0, such as register + immediate memory operations.
* reg/reg_nonzero `r29` on PowerPC64 targets.
* freg (`f[0-31]`): 64 bit floating pointer registers
The following are clobber-only:
* `ctr`, `lr`, `xer`: commonly clobbered special-purpose registers used in inline asm
* `cr` (`cr[0-7]`, `cr`): the condition register fields, or the entire condition register.
* `vreg` (`v[0-31]`): altivec/vmx register
* `vsreg` (`vs[0-63]`): vector-scalar register
* `spe_acc`: SPE accumulator, only available for PowerPC SPE targets.
The vreg and vsreg registers technically accept `#[repr(simd)]` types, but require the experimental `altivec` or `vsx` target features to be enabled. That work seems to be tracked here, rust-lang/rust#42743.
The following cannot be used as operands for inline asm:
* `r2`: the TOC pointer, required for most PIC code.
* `r13`: the TLS pointer
* `r[29]`: Reserved for internal usage by LLVM on PowerPC
* `r[30]`: Reserved for internal usage by LLVM on PowerPC and PowerPC64
* `r31`: the frame pointer
* `vrsave`: this is effectively an unused special-purpose register.
The `preserves_flags` behavior is updated with the following behavior (Note, this is not enforceable today due to LLVM restrictions):
* All status and sticky bits of `fpscr`, `spefscr`, and `vscr` are preserved.
The following registers are unavailable:
* `mma[0-7]`: These are new "registers" available on Power10, they are 512b registers which overlay 4x vsx registers. If needed, users can mark such clobbers as vsN*4, vsN*4+1,...,vsN*4+3.
* `ap`: This is actually a pseudo-register in gcc/llvm.
* `mq`: This register is only available on Power1 and Power2, and is not supported by llvm.
---
cc @taiki-e
r? @Amanieu
@rustbot label +A-inline-assembly
From the `parser` module to the `errors` module, which is where most of
its uses are.
This means the `errors` module no longer depends on the `parser` module,
removing a cyclic dependency between the two modules.
Every diagnostic struct in `rustc_parse` is in the `errors` module,
except for `ForbiddenLetReason` and `MisspelledKw`. There's no good
reason for this, and presumably it is just an accidental inconsistency.
This commit moves them into `errors`.
It contains the `Cursor` type and an `impl Cursor` block with a few
methods. But there is a larger `impl Cursor` block in the crate root.
The only other thing in the `cursor` module is the simple
`FrontmatterAllowed` type.
So this commit just moves everything in the `cursor` module (which isn't
much) into the crate root.
Switch to parsing float literals for overflow checks using
`rustc_apfloat` rather than host floats. This avoids small variations in
platform support and makes it possible to start checking `f16` and
`f128` as well.
Using APFloat matches what we try to do elsewhere to avoid platform
inconsistencies.
I tried removing it in #151203, to replace it with something simpler.
But a couple of fuzzing failures have come up and I don't have a clear
picture on how to fix them. So I'm reverting the main part of #151203.
This commit also adds the two fuzzing tests.
Fixes#151226, #151358.
`cold_path` has been around unstably for a while and is a rather useful
tool to have. It does what it is supposed to and there are no known
remaining issues, so stabilize it here (including const).
Newly stable API:
// in core::hint
pub const fn cold_path();
I have opted to exclude `likely` and `unlikely` for now since they have
had some concerns about ease of use that `cold_path` doesn't suffer
from. `cold_path` is also significantly more flexible; in addition to
working with boolean `if` conditions, it can be used in `match` arms,
`if let`, closures, and other control flow blocks. `likely` and
`unlikely` are also possible to implement in user code via `cold_path`,
if desired.
Suggest changing `iter`/`into_iter` when the other was meant
When encountering a call to `iter` that should have been `into_iter` and vice-versa, provide a structured suggestion:
```
error[E0271]: type mismatch resolving `<IntoIter<{integer}, 3> as IntoIterator>::Item == &{integer}`
--> $DIR/into_iter-when-iter-was-intended.rs:5:37
|
LL | let _a = [0, 1, 2].iter().chain([3, 4, 5].into_iter());
| ----- ^^^^^^^^^^^^^^^^^^^^^ expected `&{integer}`, found integer
| |
| required by a bound introduced by this call
|
note: the method call chain might not have had the expected associated types
--> $DIR/into_iter-when-iter-was-intended.rs:5:47
|
LL | let _a = [0, 1, 2].iter().chain([3, 4, 5].into_iter());
| --------- ^^^^^^^^^^^ `IntoIterator::Item` is `{integer}` here
| |
| this expression has type `[{integer}; 3]`
note: required by a bound in `std::iter::Iterator::chain`
--> $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL
help: consider not consuming the `[{integer}, 3]` to construct the `Iterator`
|
LL - let _a = [0, 1, 2].iter().chain([3, 4, 5].into_iter());
LL + let _a = [0, 1, 2].iter().chain([3, 4, 5].iter());
|
```
Finish addressing the original case in rust-lang/rust#68095. Only the case of chaining a `Vec` or `[]` is left unhandled.
Remove uses of `&mut CmResolver`
Before rust-lang/rust#148329, using CmResolver in closures was not possible when trying to reborrow. This pr changes uses of `&mut CmResolver` into a bare `CmResolver`, to keep the code clean (and to not have `&mut &mut Resolver`)
r? @petrochenkov
So that `pub-priv1.rs` test does not have to (ab)use the `aux-crate`
directive for this purpose.
This is very edge-casey so I don't think we should document this in
rustc-dev-guide. If someone needs to do this they will look at the code
and easily find the functionality.
This is a bit hacky since `--extern priv:pm.rs` is not valid, but we can
make our directives work however we want. And I think this is a fine
pragmatic approach. Doing it "the right way" would be a lot of work for
not much gain. Plus, that work can be done incrementally in small steps
in the future if wanted.
The existing `aarch64-unknown-none` target assumes Armv8.0-A as a baseline. However, Arm recently released the Arm Cortex-R82 processor which is the first to implement the Armv8-R AArch64 mode architecture. This architecture is similar to Armv8-A AArch64, however it has a different set of mandatory features, and is based off of Armv8.4. It is largely unrelated to the existing Armv8-R architecture target (`armv8r-none-eabihf`), which only operates in AArch32 mode.
The second `aarch64v8r-unknown-none-softfloat` target allows for possible Armv8-R AArch64 CPUs with no FPU, or for use-cases where FPU register stacking is not desired. As with the existing `aarch64-unknown-none` target we have coupled FPU support and Neon support together - there is no 'has FPU but does not have NEON' target proposed even though the architecture technically allows for it.
This PR was developed by Ferrous Systems on behalf of Arm. Arm is the owner of these changes.
- Added `RecordSpread` enum to distinguish between no spread, field defaults, and spread expressions
- Updated `FieldData` to include `default_value` field
- Modified record literal lowering to handle default field values
- Updated diagnostics to check for missing fields considering defaults
- Added methods to get matched fields for records for completions
- Enhanced hover support for struct rest patterns
Rollup of 2 pull requests
Successful merges:
- rust-lang/rust#151612 (Update documentation for `cold_path`, `likely`, and `unlikely`)
- rust-lang/rust#151670 (compiletest: Parse aux `proc-macro` directive into struct)
Update documentation for `cold_path`, `likely`, and `unlikely`
* Add a note recommending benchmarks to `cold_path`, as other hints have
* Note that `cold_path` can be used to implement `likely` and `unlikely`
* Update the tracking issue for the `likely_unlikely` feature
Tracking issue: https://github.com/rust-lang/rust/issues/136873
Tracking issue: https://github.com/rust-lang/rust/issues/151619
Fix broken WASIp1 reference link
### Location (URL)
https://doc.rust-lang.org/rustc/platform-support/wasm32-wasip1.html
<img width="800" alt="image" src="https://github.com/user-attachments/assets/b9402b3a-db7b-405f-b4ef-d849c03ad893" />
### Summary
The WASIp1 reference link in the `wasm32-wasip1` platform documentation currently points to a path that no longer exists in the WASI repository.
The WASI project recently migrated the WASI 0.1 (preview1) documentation from the `legacy/preview1` directory to the dedicated `wasi-0.1` branch (WebAssembly/WASI#855).
This updates the link to point to the intended historical WASIp1 reference, which matches the documented intent of the `wasm32-wasip1` target.
Add a `documentation` remapping path scope for rustdoc usage
This PR adds a new remapping path scope for rustdoc usage: `documentation`, instead of rustdoc abusing the other scopes for it's usage.
Like remapping paths in rustdoc, this scope is unstable. (rustdoc doesn't even have yet an equivalent to [rustc `--remap-path-scope`](https://doc.rust-lang.org/nightly/rustc/remap-source-paths.html#--remap-path-scope)).
I also took the opportunity to add a bit of documentation in rustdoc book.
compiletest: add implied `needs-target-std` for `codegen` mode tests unless annotated with `#![no_std]`/`#![no_core]`
A `codegen` mode test (such as `codegen-llvm` test suite) will now by default have an implied `//@ needs-target-std` directive, *unless* the test explicitly has an `#![no_std]`/`#![no_core]` attribute which disables this behavior.
- When a test has both `#![no_std]`/`#![no_core]` and `//@ needs-target-std`, the explicit `//@ needs-target-std` directive will cause the test to be ignored for targets that do not support std still.
This is to make it easier to test out-of-tree targets / custom targets (and targets not tested in r-l/r CI) without requiring target maintainers to do a bunch of manual `//@ needs-target-std` busywork.
Context: [#t-compiler/help > `compiletest` cannot find `core` library for target != host](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.60compiletest.60.20cannot.20find.20.60core.60.20library.20for.20target.20!.3D.20host/with/568652419)
## Implementation remarks
This is an alternative version of https://github.com/rust-lang/rust/pull/150672, with some differences:
- *This* PR applies this implied-`needs-target-std` behavior to all `codegen` test mode tests.
- *This* PR does the synthetic directive injection in the same place as implied-`codegen-run` directives. Both are of course hacks, but at least they're together next to each other.
refactor rustc-hash integration
I found that rustc-hash is used in multiple compiler crates. Also some types use `FxBuildHasher` whereas others use `BuildHasherDefault<FxHasher>` (both do the same thing).
In order to simplify future hashing experiments, I changed every location to use `rustc_data_structures::fx::*` types instead, and also removed the `BuildHasherDefault` variant. This will simplify future experiments with hashing (for example trying out a hasher that doesn't implement `Default` for whatever reason).
A `codegen-llvm` test (and other codegen test mode tests) will now by
default have an implied `//@ needs-target-std` directive, *unless* the
test explicitly has an `#![no_std]`/`#![no_core]` attribute which
disables this implied behavior.
- When a test has both `#![no_std]`/`#![no_core]` and `//@
needs-target-std`, the explicit `//@ needs-target-std` directive will
cause the test to be ignored for targets that do not support std
still.
This is to make it easier to test out-of-tree targets / custom targets
(and targets not tested in r-l/r CI) without requiring target
maintainers to do a bunch of manual `//@ needs-target-std` busywork.
Co-authored-by: Edoardo Marangoni <ecmm@anche.no>
When encountering a call to `iter` that should have been `into_iter` and vice-versa, provide a structured suggestion:
```
error[E0271]: type mismatch resolving `<IntoIter<{integer}, 3> as IntoIterator>::Item == &{integer}`
--> $DIR/into_iter-when-iter-was-intended.rs:5:37
|
LL | let _a = [0, 1, 2].iter().chain([3, 4, 5].into_iter());
| ----- ^^^^^^^^^^^^^^^^^^^^^ expected `&{integer}`, found integer
| |
| required by a bound introduced by this call
|
note: the method call chain might not have had the expected associated types
--> $DIR/into_iter-when-iter-was-intended.rs:5:47
|
LL | let _a = [0, 1, 2].iter().chain([3, 4, 5].into_iter());
| --------- ^^^^^^^^^^^ `IntoIterator::Item` is `{integer}` here
| |
| this expression has type `[{integer}; 3]`
note: required by a bound in `std::iter::Iterator::chain`
--> $SRC_DIR/core/src/iter/traits/iterator.rs:LL:COL
help: consider not consuming the `[{integer}, 3]` to construct the `Iterator`
|
LL - let _a = [0, 1, 2].iter().chain([3, 4, 5].into_iter());
LL + let _a = [0, 1, 2].iter().chain([3, 4, 5].iter());
|
```
Based on earlier work by León Orell Valerian Liehr.
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
Signed-off-by: Usman Akinyemi <uniqueusman@archlinux>
LoongArch: Fix direct-access-external-data test
On LoongArch targets, `-Cdirect-access-external-data` defaults to `no`. Since copy relocations are not supported, `dso_local` is not emitted under `-Crelocation-model=static`, unlike on other targets.
Fix suppression of `unused_assignment` in binding of `unused_variable`
Unused assignments to an unused variable should trigger only the `unused_variables` lint and not also the `unused_assignments` lint. This was previously implemented by checking whether the span of the assignee was within the span of the binding pattern, however that failed to capture situations was imported from elsewhere (eg from the input tokenstream of a proc-macro that generates the binding pattern).
By comparing the span of the assignee to those of the variable introductions instead, a reported stable-to-stable regression is resolved.
This fix also impacted some other preexisting tests, which had (undesirably) been triggering both the `unused_variables` and `unused_assignments` lints on the same initializing assignment; those tests have therefore now been updated to expect only the former lint.
Fixesrust-lang/rust#151514
r? cjgillot (as author of reworked liveness testing in rust-lang/rust#142390)
The SSE2 helper function is not inlined across crate boundaries,
so we cannot verify the codegen in an assembly test. The fix is
still verified by the absence of performance regression.
Fix 'the the' typo in library/core/src/array/iter.rs
This PR fixes a small grammatical error in a safety comment within `library/core/src/array/iter.rs` where the word "the" was duplicated.
No functional changes.
Rename `DepKindStruct` to `DepKindVTable`
This type is used by dependency-tracking code in the query system, for looking up function pointers and other metadata associated with a particular `DepKind`.
Calling it “struct” is not particularly helpful, whereas calling it a “vtable” at least gives some basic intuition for what it is and how it is used.
Some associated identifiers have also drifted a bit over time, and this PR adjusts those as well.
There should be no change to compiler behaviour.
r? nnethercote (or compiler)
x86 soft-float feature: mark it as forbidden rather than unstable
I am not sure why I made it "unstable" in f755f4cd1a; I think at the time "forbidden" did not work for some reason.
Making it "forbidden" instead has no significant effect on `-Ctarget-feature` use, it just changes the warning. It *does* have the effect that one cannot query this using `cfg(target_feature)` on nightly any more, but that seems fine to me. It only ever worked as an accidental side-effect of f755f4cd1a anyway.
r? @workingjubilee
Various refactors to the proc_macro bridge
This reduces the amount of types, traits and other abstractions that are involved with the bridge, which should make it easier to understand and modify. This should also help a bit with getting rid of the type marking hack, which is complicating the code a fair bit.
Fixes: rust-lang/rust#139810
Fix(lib/win/thread): Ensure `Sleep`'s usage passes over the requested duration under Win7
Fixesrust-lang/rust#149935. See the added comment for more details.
This makes the concerned test now reproducibly pass, for us at least. Also, testing this separately revealed successful: see the issue.
@rustbot label C-bug I-flaky-test O-windows-7 T-libs A-time A-thread
add CSE optimization tests for iterating over slice
This PR is regression test for issue rust-lang/rust#119573.
This PR introduces a new regression test to verify a critical optimization known as Common Subexpression Elimination (CSE) is correctly applied during various slice iteration patterns.
std: avoid tearing `dbg!` prints
Fixes https://github.com/rust-lang/rust/issues/136703.
This is an alternative to rust-lang/rust#149859. Instead of formatting everything into a string, this PR makes multi-expression `dbg!` expand into multiple nested matches, with the final match containing a single `eprint!`. By using macro recursion and relying on hygiene, this allows naming every bound value in that `eprint!`.
CC @orlp
r? libs
std: avoid tearing `dbg!` prints
Fixes https://github.com/rust-lang/rust/issues/136703.
This is an alternative to rust-lang/rust#149859. Instead of formatting everything into a string, this PR makes multi-expression `dbg!` expand into multiple nested matches, with the final match containing a single `eprint!`. By using macro recursion and relying on hygiene, this allows naming every bound value in that `eprint!`.
CC @orlp
r? libs
abi: add a rust-preserve-none calling convention
This is the conceptual opposite of the rust-cold calling convention and is particularly useful in combination with the new `explicit_tail_calls` feature.
For relatively tight loops implemented with tail calling (`become`) each of the function with the regular calling convention is still responsible for restoring the initial value of the preserved registers. So it is not unusual to end up with a situation where each step in the tail call loop is spilling and reloading registers, along the lines of:
foo:
push r12
; do things
pop r12
jmp next_step
This adds up quickly, especially when most of the clobberable registers are already used to pass arguments or other uses.
I was thinking of making the name of this ABI a little less LLVM-derived and more like a conceptual inverse of `rust-cold`, but could not come with a great name (`rust-cold` is itself not a great name: cold in what context? from which perspective? is it supposed to mean that the function is rarely called?)
abi: add a rust-preserve-none calling convention
This is the conceptual opposite of the rust-cold calling convention and is particularly useful in combination with the new `explicit_tail_calls` feature.
For relatively tight loops implemented with tail calling (`become`) each of the function with the regular calling convention is still responsible for restoring the initial value of the preserved registers. So it is not unusual to end up with a situation where each step in the tail call loop is spilling and reloading registers, along the lines of:
foo:
push r12
; do things
pop r12
jmp next_step
This adds up quickly, especially when most of the clobberable registers are already used to pass arguments or other uses.
I was thinking of making the name of this ABI a little less LLVM-derived and more like a conceptual inverse of `rust-cold`, but could not come with a great name (`rust-cold` is itself not a great name: cold in what context? from which perspective? is it supposed to mean that the function is rarely called?)
Other hints have a note recommending benchmarks to ensure they actually
do what is intended. This is also applicable for `cold_path`, so add a
note here.
Fix cstring-merging test for Hexagon target
Hexagon assembler uses `.string` directive instead of `.asciz` for null-terminated strings. Both are equivalent but the test was only checking for `.asciz`.
Update the CHECK patterns to accept both directives using `.{{asciz|string}}` regex pattern.
Extend build-manifest local test guide
Fill in more blanks about how to test build-manifest changes with Rustup.
Figured this out while working on https://github.com/rust-lang/rust/pull/151156, with the help of bjorn3.
Add Korean translation to Rust By Example
Hello,
I’ve added a Korean translation file to Rust By Example.
This contribution will help Korean readers learn Rust more easily by providing localized explanations and examples.
Please review the proposed additions when you have time.
Thanks in advance for your time and review! 🙏
Add Korean translation. Thanks in advance.
std: `sleep_until` on Motor and VEX
This PR:
* Forwards the public `sleep_until` to the private `sleep_until` on Motor OS
* Adds a `sleep_until` implementation on VEX that yields until the deadline has passed
CC @lasiotus
CC @lewisfm @tropicaaal @Gavin-Niederman @max-niederman
add `simd_splat` intrinsic
Add `simd_splat` which lowers to the LLVM canonical splat sequence.
```llvm
insertelement <N x elem> poison, elem %x, i32 0
shufflevector <N x elem> v0, <N x elem> poison, <N x i32> zeroinitializer
```
Right now we try to fake it using one of
```rust
fn splat(x: u32) -> u32x8 {
u32x8::from_array([x; 8])
}
```
or (in `stdarch`)
```rust
fn splat(value: $elem_type) -> $name {
#[derive(Copy, Clone)]
#[repr(simd)]
struct JustOne([$elem_type; 1]);
let one = JustOne([value]);
// SAFETY: 0 is always in-bounds because we're shuffling
// a simd type with exactly one element.
unsafe { simd_shuffle!(one, one, [0; $len]) }
}
```
Both of these can confuse the LLVM optimizer, producing sub-par code. Some examples:
- https://github.com/rust-lang/rust/issues/60637
- https://github.com/rust-lang/rust/issues/137407
- https://github.com/rust-lang/rust/issues/122623
- https://github.com/rust-lang/rust/issues/97804
---
As far as I can tell there is no way to provide a fallback implementation for this intrinsic, because there is no `const` way of evaluating the number of elements (there might be issues beyond that, too). So, I added implementations for all 4 backends.
Both GCC and const-eval appear to have some issues with simd vectors containing pointers. I have a workaround for GCC, but haven't yet been able to make const-eval work. See the comments below.
Currently this just adds the intrinsic, it does not actually use it anywhere yet.
compiletest: Make `aux-crate` directive explicitly handle `--extern` modifiers
With `-Zunstable-options` it is possible to pass options to `--extern`. See here for an exhaustive list of possible options:
b5dd72d292/compiler/rustc_session/src/config.rs (L2356-L2367)
Using these options works with the `aux-crate` directive, but only because the options pretend to be part of the name. Make it clearer what `aux-crate` supports by explicitly handling `--extern` options.
This PR is step one of splitting up https://github.com/rust-lang/rust/pull/151258 into smaller pieces.
r? @Zalathar
add `simd_splat` intrinsic
Add `simd_splat` which lowers to the LLVM canonical splat sequence.
```llvm
insertelement <N x elem> poison, elem %x, i32 0
shufflevector <N x elem> v0, <N x elem> poison, <N x i32> zeroinitializer
```
Right now we try to fake it using one of
```rust
fn splat(x: u32) -> u32x8 {
u32x8::from_array([x; 8])
}
```
or (in `stdarch`)
```rust
fn splat(value: $elem_type) -> $name {
#[derive(Copy, Clone)]
#[repr(simd)]
struct JustOne([$elem_type; 1]);
let one = JustOne([value]);
// SAFETY: 0 is always in-bounds because we're shuffling
// a simd type with exactly one element.
unsafe { simd_shuffle!(one, one, [0; $len]) }
}
```
Both of these can confuse the LLVM optimizer, producing sub-par code. Some examples:
- https://github.com/rust-lang/rust/issues/60637
- https://github.com/rust-lang/rust/issues/137407
- https://github.com/rust-lang/rust/issues/122623
- https://github.com/rust-lang/rust/issues/97804
---
As far as I can tell there is no way to provide a fallback implementation for this intrinsic, because there is no `const` way of evaluating the number of elements (there might be issues beyond that, too). So, I added implementations for all 4 backends.
Both GCC and const-eval appear to have some issues with simd vectors containing pointers. I have a workaround for GCC, but haven't yet been able to make const-eval work. See the comments below.
Currently this just adds the intrinsic, it does not actually use it anywhere yet.
Fix(lib/win/net): Remove hostname support under Win7
Fixesrust-lang/rust#150896. `GetHostNameW` is not available under Windows 7, leading to dynamic linking failures upon program executions. For now, as it is still unstable, this therefore appropriately cfg-gates the feature in order to mark the Win7 as unsupported with regards to this particular feature. Porting the functionality for Windows 7 would require changing the underlying system call and so more work for the immediate need.
@rustbot label C-bug O-windows-7 T-libs A-io
Add new Tier 3 targets for ARMv6
Adds three new targets to support ARMv6 processors running bare-metal:
* `armv6-none-eabi` - Arm ISA, soft-float
* `armv6-none-eabihf` - Arm ISA, hard-float
* `thumbv6-none-eabi` - Thumb-1 ISA, soft-float
There is no `thumbv6-none-eabihf` target because as far as I can tell, hard-float isn't support with the Thumb-1 instruction set (and you need the ARMv6T2 extension to enable Thumb-2 support).
The targets require ARMv6K as a minimum, which allows the two Arm ISA targets to have full CAS atomics. LLVM has a bug which means it emits some ARMv6K instructions even if you only call for ARMv6, and as no-one else has noticed the bug, and because basically all ARMv6 processors have ARMv6K, I think this is fine. The Thumb target also doesn't have any kind of atomics, just like the Armv5TE and Armv4 targets, because LLVM was emitting library calls to emulate them.
Testing will be added to https://github.com/rust-embedded/aarch32 once the target is accepted. I already have tests for the other non-M arm-none-eabi targets, and those tests pass on these targets.
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
I have listed myself. If accepted, I'll talk to the Embedded Devices Working Group about adding this one to the rosta with all the others they support.
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
You might prefer `arm-none-eabi`, because `arm-unknown-linux-gnu` is an ARMv6 target - the implicit rule seems to be that if the Arm architecture version isn't specified, it's assumed to be v6. However, `armv6-none-eabi` seemed to fit better between `armv5te-none-eabi` and `armv7a/armv7r-none-eabi`.
The hamming distance between `thumbv6-none-eabi` and `thumbv6m-none-eabi` is unfortunately low, but I don't know how to make it better. They *are* the ARMv6 and ARMv6-M targets, and its perhaps not worse than `armv7a-none-eabi` and `armv7r-none-eabi`.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
No different to any other arm-none-eabi target.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
Noted.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate...
Same as other arm-none-eabi targets.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible.
Same as other arm-none-eabi targets.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
Noted.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
Noted
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.)
Noted
Three targets, covering A32 and T32 instructions, and soft-float and
hard-float ABIs. Hard-float not available in Thumb mode. Atomics
in Thumb mode require __sync* functions from compiler-builtins.
This is the conceptual opposite of the rust-cold calling convention and
is particularly useful in combination with the new `explicit_tail_calls`
feature.
For relatively tight loops implemented with tail calling (`become`) each
of the function with the regular calling convention is still responsible
for restoring the initial value of the preserved registers. So it is not
unusual to end up with a situation where each step in the tail call loop
is spilling and reloading registers, along the lines of:
foo:
push r12
; do things
pop r12
jmp next_step
This adds up quickly, especially when most of the clobberable registers
are already used to pass arguments or other uses.
I was thinking of making the name of this ABI a little less LLVM-derived
and more like a conceptual inverse of `rust-cold`, but could not come
with a great name (`rust-cold` is itself not a great name: cold in what
context? from which perspective? is it supposed to mean that the
function is rarely called?)
This is the conceptual opposite of the rust-cold calling convention and
is particularly useful in combination with the new `explicit_tail_calls`
feature.
For relatively tight loops implemented with tail calling (`become`) each
of the function with the regular calling convention is still responsible
for restoring the initial value of the preserved registers. So it is not
unusual to end up with a situation where each step in the tail call loop
is spilling and reloading registers, along the lines of:
foo:
push r12
; do things
pop r12
jmp next_step
This adds up quickly, especially when most of the clobberable registers
are already used to pass arguments or other uses.
I was thinking of making the name of this ABI a little less LLVM-derived
and more like a conceptual inverse of `rust-cold`, but could not come
with a great name (`rust-cold` is itself not a great name: cold in what
context? from which perspective? is it supposed to mean that the
function is rarely called?)
fixesrust-lang/rust-clippy#16433
Adds a trailing comma to the last field of a struct pattern if it ends
with a `..` to avoid an invalid suggestion. A test was added as well.
changelog: [`manual_let_else`] fix suggestion for `..` patterns
THIR patterns: Explicitly distinguish `&pin` from plain `&`/`&mut`
Currently, `thir::PatKind::Deref` is used for ordinary `&`/`&mut` patterns, and also for `&pin const` and `&pin mut` patterns under `feature(pin_ergonomics)`. The only way to distinguish between them is by inspecting the `Ty` attached to the pattern node.
That's non-obvious, making it easy to miss, and is also a bit confusing to read when it does occur.
This PR therefore adds an explicit `pin: hir::Pinnedness` field to `thir::PatKind::Deref`, to explicitly distinguish pin-deref nodes from ordinary builtin-deref nodes.
(I'm not deeply familiar with the future of pin-patterns, so I'm not sure whether that information is best carried as a field or as a separate `PatKind`, but I think this approach is at least an improvement over the status quo.)
r? Nadrieril (or compiler)
`const` blocks as a `mod` item
Tracking issue: rust-lang/rust#149226
This adds support for writing `const { ... }` as an item in a module. In the current implementation, this is a unique AST item that gets lowered to `const _: () = const { ... };` in HIR.
rustfmt support included.
TODO:
- `pub const { ... }` does not make sense (see rust-lang/rust#147136). Reject it. Should this be rejected by the parser or smth?
- Improve diagnostics (preferably they should not mention the fake `_` ident).
Example
---
```rust
fn foo() {
$0for mut i in 3..7 {
foo(i);
continue;
bar(i);
}
}
```
**Before this PR**
This may cause an infinite loop
```rust
fn foo() {
let mut i = 3;
while i < 7 {
foo(i);
continue;
bar(i);
i += 1;
}
}
```
**After this PR**
```rust
fn foo() {
let mut i = 3;
while i < 7 {
'cont: {
foo(i);
break 'cont;
bar(i);
}
i += 1;
}
}
```
This fixes stage1 builds when the proc-macro bridge api changed.
The rustc_proc_macro crate is identical to the proc_macro that would end
up in the sysroot of the rustc compiler rustc_proc_macro is linked into.
Fix compilation of std/src/sys/pal/uefi/tests.rs
Dropped the `align` test since the `POOL_ALIGNMENT` and `align_size` items it uses do not exist.
The other changes are straightforward fixes for places where the test code drifted from the current API, since the tests are not yet built in CI for the UEFI target.
CC @Ayush1325
Don't use default build-script fingerprinting in `test`
This changes the `test` build script so that it does not use the default fingerprinting mechanism in cargo which causes a full scan of the package every time it runs. This build script does not depend on any of the files in the package.
This is the recommended approach for writing build scripts.
Add "Skip to main content" link for keyboard navigation in rustdoc
## Summary
This PR adds a "Skip to main content" link for keyboard navigation in rustdoc, improving accessibility by allowing users to bypass the sidebar and navigate directly to the main content area.
## Changes
- **`src/librustdoc/html/templates/page.html`**: Added a skip link (`<a class="skip-main-content">`) immediately after the `<body>` tag that links to `#main-content`
- **`src/librustdoc/html/static/css/rustdoc.css`**: Added CSS styles for the skip link:
- Visually hidden by default (`position: absolute; top: -100%`)
- Becomes visible when focused via Tab key (`top: 0` on `:focus`)
- Styled consistently with rustdoc theme using existing CSS variables
- **`tests/rustdoc-gui/skip-navigation.goml`**: Added GUI test to verify the skip link functionality
## WCAG Compliance
This addresses **WCAG Success Criterion 2.4.1 (Level A)** - Bypass Blocks:
> A mechanism is available to bypass blocks of content that are repeated on multiple web pages.
## Demo
When pressing Tab on a rustdoc page, the first focusable element is now the "Skip to main content" link, allowing keyboard users to jump directly to the main content without tabbing through the entire sidebar.
## Future Improvements
Based on the discussion in rust-lang/rust#151420, additional skip links could be added between the page summary and module contents sections. This PR provides the foundation, and we can iterate on adding more skip links based on feedback.
Fixesrust-lang/rust#151420
r? @JayanAXHF
Enable reproducible binary builds with debuginfo on Linux
Fixesrust-lang/rust#89911
This PR enables `-Cdebuginfo=2` for binary crate types in the `reproducible-build` run-make test on Linux platforms.
- Removed the `!matches!(crate_type, CrateType::Bin)` check in `diff_dir_test()`
- SHA256 hashes match: `932be0d950f4ffae62451f7b4c8391eb458a68583feb11193dd501551b6201d4`
This scenario was previously disabled due to rust-lang/rust#89911. I have verified locally on Linux (WSL) with LLVM 21 that the regression reported in that issue appears to be resolved, and the tests now pass with debug info enabled.
Fix is_ascii performance regression on AVX-512 CPUs when compiling with -C target-cpu=native
## Summary
This PR fixes a severe performance regression in `slice::is_ascii` on AVX-512 CPUs when compiling with `-C target-cpu=native`.
On affected systems, the current implementation achieves only ~3 GB/s for large inputs, compared to ~60–70 GB/s previously (≈20–24× regression). This PR restores the original performance characteristics.
This change is intended as a **temporary workaround** for upstream LLVM poor codegen. Once the underlying LLVM issue is fixed and Rust is able to consume that fix, this workaround should be reverted.
## Problem
When `is_ascii` is compiled with AVX-512 enabled, LLVM's auto-vectorization generates ~31 `kshiftrd` instructions to extract mask bits one-by-one, instead of using the efficient `pmovmskb`
instruction. This causes a **~22x performance regression**.
Because `is_ascii` is marked `#[inline]`, it gets inlined and recompiled with the user's target settings, affecting anyone using `-C target-cpu=native` on AVX-512 CPUs.
## Root cause (upstream)
The underlying issue appears to be an LLVM vectorizer/backend bug affecting certain AVX-512 patterns.
An upstream issue has been filed by @folkertdev to track the root cause: llvm/llvm-project#176906
Until this is resolved in LLVM and picked up by rustc, this PR avoids triggering the problematic codegen pattern.
## Solution
Replace the counting loop with explicit SSE2 intrinsics (`_mm_movemask_epi8`) that force `pmovmskb` codegen regardless of CPU features.
## Godbolt Links (Rust 1.92)
| Pattern | Target | Link | Result |
|---------|--------|------|--------|
| Counting loop (old) | Default SSE2 | https://godbolt.org/z/sE86xz4fY | `pmovmskb` |
| Counting loop (old) | AVX-512 (znver4) | https://godbolt.org/z/b3jvMhGd3 | 31x `kshiftrd` (broken) |
| SSE2 intrinsics (fix) | Default SSE2 | https://godbolt.org/z/hMeGfeaPv | `pmovmskb` |
| SSE2 intrinsics (fix) | AVX-512 (znver4) | https://godbolt.org/z/Tdvdqjohn | `vpmovmskb` (fixed) |
## Benchmark Results
**CPU:** AMD Ryzen 5 7500F (Zen 4 with AVX-512)
### Default Target (SSE2) — Mixed
| Size | Before | After | Change |
|------|--------|-------|--------|
| 4 B | 1.8 GB/s | 2.0 GB/s | **+11%** |
| 8 B | 3.2 GB/s | 5.8 GB/s | **+81%** |
| 16 B | 5.3 GB/s | 8.5 GB/s | **+60%** |
| 32 B | 17.7 GB/s | 15.8 GB/s | -11% |
| 64 B | 28.6 GB/s | 25.1 GB/s | -12% |
| 256 B | 51.5 GB/s | 48.6 GB/s | ~same |
| 1 KB | 64.9 GB/s | 60.7 GB/s | ~same |
| 4 KB+ | ~68-70 GB/s | ~68-72 GB/s | ~same |
### Native Target (AVX-512) — Up to 24x Faster
| Size | Before | After | Speedup |
|------|--------|-------|---------|
| 4 B | 1.2 GB/s | 2.0 GB/s | **1.7x** |
| 8 B | 1.6 GB/s | 5.0 GB/s | **3.3x** |
| 16 B | ~7 GB/s | ~7 GB/s | ~same |
| 32 B | 2.9 GB/s | 14.2 GB/s | **4.9x** |
| 64 B | 2.9 GB/s | 23.2 GB/s | **8x** |
| 256 B | 2.9 GB/s | 47.2 GB/s | **16x** |
| 1 KB | 2.8 GB/s | 60.0 GB/s | **21x** |
| 4 KB+ | 2.9 GB/s | ~68-70 GB/s | **23-24x** |
### Summary
- **SSE2 (default):** Small inputs (4-16 B) 11-81% faster; 32-64 B ~11% slower; large inputs unchanged
- **AVX-512 (native):** 21-24x faster for inputs ≥1 KB, peak ~70 GB/s (was ~3 GB/s)
Note: this is the pure ascii path, but the story is similar for the others.
See linked bench project.
## Test Plan
- [x] Assembly test (`slice-is-ascii-avx512.rs`) verifies no `kshiftrd` with AVX-512
- [x] Existing codegen test updated to `loongarch64`-only (auto-vectorization still used there)
- [x] Fuzz testing confirms old/new implementations produce identical results (~53M iterations)
- [x] Benchmarks confirm performance improvement
- [x] Tidy checks pass
## Reproduction / Test Projects
Standalone validation tools: https://github.com/bonega/is-ascii-fix-validation
- `bench/` - Criterion benchmarks for SSE2 vs AVX-512 comparison
- `fuzz/` - Compares old/new implementations with libfuzzer
## Related Issues
- issue opened by @folkertdev llvm/llvm-project#176906
- Regression introduced in https://github.com/rust-lang/rust/pull/130733
Add Tier 3 Thumb-mode targets for Armv7-A, Armv7-R and Armv8-R
We currently have targets for bare-metal Armv7-R, Armv7-A and Armv8-R, but only in Arm mode. This PR adds five new targets enabling bare-metal support on these architectures in Thumb mode.
This has been tested using https://github.com/rust-embedded/aarch32/compare/main...thejpster:aarch32:support-thumb-mode-v7-v8?expand=1 and they all seem to work as expected.
However, I wasn't sure what to do with the maintainer lists as these are five new targets, but they share the docs page with the existing Arm versions. I can ask the Embedded Devices WG Arm Team about taking on these ones too, but whether Arm themselves want to take them on I guess is a bigger question.
Hexagon assembler uses `.string` directive instead of `.asciz` for
null-terminated strings. Both are equivalent but the test was only
checking for `.asciz`.
Update the CHECK patterns to accept both directives using
`.{{asciz|string}}` regex pattern.
* hexagon-unknown-qurt: Use hexagon-clang from Hexagon SDK instead of
rust-lld
* hexagon-unknown-linux-musl: Use hexagon-unknown-linux-musl-clang from
the open source toolchain instead of rust-lld.
* hexagon-unknown-none-elf: Keep rust-lld but fix the linker flavor.
rust-lld is appropriate for a baremetal target but for traditional
programs that depend on libc, using clang's driver makes the most
sense.
Unused assignments to an unused variable should trigger only the
`unused_variables` lint and not also the `unused_assignments` lint.
This was previously implemented by checking whether the span of the
assignee was within the span of the binding pattern, however that failed
to capture situations was imported from elsewhere (eg from the input
tokenstream of a proc-macro that generates the binding pattern).
By comparing the span of the assignee to those of the variable
introductions instead, a reported stable-to-stable regression is
resolved.
This fix also impacted some other preexisting tests, which had
(undesirably) been triggering both the `unused_variables` and
`unused_assignments` lints on the same initializing assignment; those
tests have therefore now been updated to expect only the former lint.
Dropped the `align` test since the `POOL_ALIGNMENT` and `align_size`
items it uses do not exist.
The other changes are straightforward fixes for places where the test
code drifted from the current API, since the tests are not yet built in
CI for the UEFI target.
This makes rustc simply return an exit code from main rather than calling `std::process::exit` with an exit code. This means that drops run normally and the process exits cleanly.
Also instead of hard coding success and failure codes this uses `ExitCode::SUCCESS` and `ExitCode::FAILURE`, which in turn effectively uses `libc::EXIT_SUCCESS` and `libc::EXIT_FAILURE` (via std). These are `0` and `1` respectively for all currently supported host platforms so it doesn't actually change the exit code.
This makes rustc simply return an exit code from main rather than calling `std::process::exit` with an exit code. This means that drops run normally and the process exits cleanly.
Also instead of hard coding success and failure codes this uses `ExitCode::SUCCESS` and `ExitCode::FAILURE`, which in turn effectively uses `libc::EXIT_SUCCESS` and `libc::EXIT_FAILURE` (via std). These are `0` and `1` respectively for all currently supported host platforms so it doesn't actually change the exit code.
This changes the `test` build script so that it does not use the default
fingerprinting mechanism in cargo which causes a full scan of the
package every time it runs. This build script does not depend on any of
the files in the package.
This is the recommended approach for writing build scripts.
Clean up or resolve cfg-related instances of `FIXME(f16_f128)`
* Replace target-specific config that has a `FIXME` with `cfg(target_has_reliable_f*)`
* Take care of trivial intrinsic-related FIXMEs
* Split `FIXME(f16_f128)` into `FIXME(f16)`, `FIXME(f128)`, or `FIXME(f16,f128)` to more clearly identify what they block
The individual commit messages have more details.
update enzyme, includes an extra patch to fix MacOS builds in CI
I updated the submodule under rust-lang/enzyme to match EnzymeAD/enzyme, and added one commit, which based on some testing should fix how we build Enzyme in the MacOS CI. Once this pr landed, we will verify again that CI still works, and afterwards upstream the patch and drop it from our fork. No new test failures.
cc @sgasho
r? @Kobzol
Rename `HandleCycleError` to `CycleErrorHandling`
In https://github.com/rust-lang/rust/pull/101303, the `handle_cycle_error` field was changed from a macro-generated closure to a macro-selected enum variant. But it was not renamed to reflect the fact that it now holds data, not code.
Renaming the field and its associated enum to `cycle_error_handling: CycleErrorHandling` should make the relevant code less confusing to read.
This PR also moves the enum out of `rustc_query_system::error`, where it was easily confused with diagnostic structs.
There should be no change to compiler behaviour.
Add -Z large-data-threshold
This flag allows specifying the threshold size for placing static data in large data sections when using the medium code model on x86-64.
When using -Ccode-model=medium, data smaller than this threshold uses RIP-relative addressing (32-bit offsets), while larger data uses absolute 64-bit addressing. This allows the compiler to generate more efficient code for smaller data while still supporting data larger than 2GB.
This mirrors the -mlarge-data-threshold flag available in GCC and Clang. The default threshold is 65536 bytes (64KB) if not specified, matching LLVM's default behavior.
inline constant localized typeck constraint computation
This fixes an oversight in the previous PRs, this constraint is local to a point (and liveness does the rest) and so has a fixed direction.
I wasn't planning on trying to improve the impl for perf, versus computing loan liveness without first unifying the cfg and subset graph, but it's like a 20x improvement for typeck constraints on wg-grammar (-15% end-to-end) for a trivial fix.
r? @jackh726
In general, I want to cleanup these edges to avoid off-by-one errors in constraints at effectful statements and ensure the midpoint-avoidance strategy is sound and works well, in particular with respect to edges that flow backwards from the result into its inputs. But I'd like to start from something that passes all tests and is simpler, because the eventual solution may
1. involve localizing these edges differently than *separate* liveness and typeck lowering passes/approaches, which would need to be lowered at the same time for example. I'm already doing the latter in the loan liveness rewrite as part of creating edges on-demand during traversal, and this new structure would be a better fit to verify, or fix, these subtle edges.
2. also require changes in MIR typeck to track the flow across points more precisely, and I don't know how hard that would be. *Computing* the constraint direction is currently a workaround for that.
Therefore, in a future PR, I'll also remove this computation from the terminator constraints, but I can also do that in this PR if you'd prefer.
This FIXME was introduced in 6e2d934a88 ("Add more `f16` and `f128`
library functions and constants") but I can't actually find my
reasoning. As far as I can tell, LLVM has been lowering `fabs.f128` as
bitwise operations for a while across all targets so there shouldn't be
a problem here.
Thus, apply what is suggested in the FIXME.
There are a number of instances of `FIXME(f16_f128)` related to target
configuration; either these could use `target_has_reliable_f128`, or the
FIXME is describing such a cfg and is thus redundant (since any
`cfg(target_has_reliable_f*)` needs to be removed before stabilization
anyway).
Switch to using `target_has_reliable_*` where applicable and remove the
redundant FIXMEs.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#151450 (std: use `clock_nanosleep` for `sleep` where available)
- rust-lang/rust#151494 (std: ensure that the deadline has passed in `sleep_until`)
- rust-lang/rust#151498 (global.rs: improve readability of re-entrance section)
- rust-lang/rust#151504 (Reorganizing tests/ui/issues 11 tests [3/N])
r? @ghost
std: use `clock_nanosleep` for `sleep` where available
`nanosleep` is specified to use `CLOCK_REALTIME` but the documentation (especially the example) for `sleep` imply that it measures time using `Instant`, which uses `CLOCK_MONOTONIC`. Thus, this PR makes `sleep` use a relative `clock_nanosleep` with `CLOCK_MONOTONIC` where available. This doesn't make a difference for Linux (which uses `CLOCK_MONOTONIC` for `nanosleep` anyway) but is relevant for e.g. FreeBSD.
This also restores nanosecond-sleep precision for WASI, since https://github.com/rust-lang/rust/issues/150290 was caused by `nanosleep` internally using `clock_nanosleep` with `CLOCK_REALTIME` which is unsupported on WASIp2.
CC @alexcrichton for the WASI fix
Remove the `#[target_feature(enable = "sse2")]` attribute and make the
function safe to call. The SSE2 requirement is already enforced by the
`#[cfg(target_feature = "sse2")]` predicate.
Individual unsafe blocks are used for intrinsic calls with appropriate
SAFETY comments.
Also adds FIXME reference to llvm#176906 for tracking when this
workaround can be removed.
Combine the x86_64 and loongarch64 is_ascii tests into a single file
using compiletest revisions. Both now test assembly output:
- X86_64: Verifies no broken kshiftrd/kshiftrq instructions (AVX-512 fix)
- LA64: Verifies vmskltz.b instruction is used (auto-vectorization)
Fix ICE when using zero-length SIMD type in extern static
before my fix using a zero-length SIMD type in an extern static would cause an internal compiler error. now it properly shows a diagnostic error instead of panicking. it was because `LayoutError::InvalidSimd` wasn't handled in `check_static_inhabited` and fell through to a generic `delayed_bug`.
i added handling for `InvalidSimd` in `check_static_inhabited` (similar to `SizeOverflow`): when a SIMD type has an invalid layout, we call `emit_err` with `Spanned` to emit a normal error instead of an ICE. compiler now emits a clear error `"the SIMD type Simd<u8, 0> has zero elements"` with the correct span on the type, matching expected compiler behavior.
fixesrust-lang/rust#151451
Previously, using a zero-length SIMD type in an extern static would
cause an internal compiler error. Now it properly emits a diagnostic
error instead of panicking.
Avoid `-> ()` in derived functions.
`hash` and `assert_receiver_is_total_eq` have no return type. This commit removes the `-> ()` that is currently printed for them.
r? @Kobzol
llvm: Tolerate dead_on_return attribute changes
The attribute now has a size parameter and sorts differently. Adjust tests to tolerate this.
https://github.com/llvm/llvm-project/pull/171712
r? durin42
@rustbot label llvm-main
fix `f16` doctest FIXMEs
tracking issue: https://github.com/rust-lang/rust/issues/116909
Remove a bunch of fixmes, and run docs tests on all targets that (should) support them.
r? tgross35
codegen: clarify some variable names around function calls
I looked at rust-lang/rust#145932 to try to understand how it works, and quickly got lost in the variable names -- what refers to the caller, what to the callee? So here's my attempt at making those more clear. Hopefully the new names are correct.^^
Cc @JamieCunliffe
Fix ICE: Don't try to evaluate type_consts when eagerly collecting items
This fixes https://github.com/rust-lang/rust/issues/151246
The change is pretty straightforward if the Monomorphization strategy is eager which `-Clink-dead-code=true` sets. This then would lead to the existing code to try and evaluate a `type const` which does not have a body to evaluate leading to an ICE. The change is pretty straight forward just skip over type consts.
This also seems like a sensible choice to me since a MonoItem can only be a Fn, Static, or Asm. A type const is none of the aforementioned.
And even if it was added to the MonoItems list it would then later fail this check:
fe98ddcfcf/compiler/rustc_monomorphize/src/collector.rs (L438-L440)
Since that explicitly checks that the MonoItem's `DefKind` is static and not anything else.
One more change is the addition of a simple test of the example code from https://github.com/rust-lang/rust/issues/151246 that checks that code compiles successfully with `-Clink-dead-code=true`.
The only other change was to make the guard checks a little easier to read by making the logic more linear instead of one big if statement.
r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args
MGCA: Fix incorrect pretty printing of valtree arrays
Fixesrust-lang/rust#151126
- **add failing test**
- **fix: additional check whether const array could be printed as raw bytes**
As I figured out, the problem was in `pretty_print_const_valtree`, where it tried to print unevaluated consts as if they were evaluated, which resulted in ICE.
Handle unevaluated ConstKind in in_operand
fix: rust-lang/rust#151248
r? BoxyUwU
~~I can't reproduce rust-lang/rust#151246 in my local(x86_64-pc-windows-msvc) even before this change. 🤔
create a draft and test it in different environments.~~
fix fallback impl for select_unpredictable intrinsic
`intrinsics::select_unpredictable` does not drop the value that is not selected, but the fallback impl did not consider this behavior. This creates an observable difference between Miri and actual execution, and possibly does not play well with the `core::hint` version which has extra logic to drop the value that was not selected.
```rust
#![feature(core_intrinsics)]
fn main() {
core::intrinsics::select_unpredictable(true, LoudDrop(0), LoudDrop(1));
// cargo run: "0"; cargo miri run: "1 0"
}
struct LoudDrop(u8);
impl Drop for LoudDrop {
fn drop(&mut self) {
print!("{} ", self.0);
}
}
```
This change let me remove the `T: [const] Destruct` bound as well, since the destructor is no longer relevant.
rustdoc: render doc(hidden) as a code attribute
Move `#[doc(hidden)]` into the shared code-attribute renderer so it matches the styling and placement of other attributes in rustdoc HTML.
Closesrust-lang/rust#132304
This is a PR for thumbv6-none-eabi (bere-metal Armv6k in Thumb mode)
which proposed to be added by
https://github.com/rust-lang/rust/pull/150138.
Armv6k supports atomic instructions, but they are unavailable in Thumb
mode unless Thumb-2 instructions available (v6t2).
Using Thumb interworking (can be used via `#[instruction_set]`) allows
us to use these instructions even from Thumb mode without Thumb-2
instructions, but LLVM does not implement that processing (as of LLVM
21), so this PR implements it in compiler-builtins.
The code around `__sync` builtins is basically copied from
`arm_linux.rs` which uses kernel_user_helpers for atomic implementation.
The atomic implementation is a port of my [atomic-maybe-uninit inline
assembly code].
This PR has been tested on QEMU 10.2.0 using patched compiler-builtins
and core that applied the changes in this PR and
https://github.com/rust-lang/rust/pull/150138 and the [portable-atomic
no-std test suite] (can be run with `./tools/no-std.sh
thumbv6-none-eabi` on that repo) which tests wrappers around
`core::sync::atomic`. (Note that the target-spec used in test sets
max-atomic-width to 32 and atomic_cas to true, unlike the current
https://github.com/rust-lang/rust/pull/150138.) The original
atomic-maybe-uninit implementation has been tested on real Arm hardware.
(Note that Armv6k also supports 64-bit atomic instructions, but they are
skipped here. This is because there is no corresponding code in
`arm_linux.rs` (since the kernel requirements increased in 1.64, it may
be possible to implement 64-bit atomics there as well. see also
https://github.com/taiki-e/portable-atomic/pull/82), the code becomes
more complex than for 32-bit and smaller atomics.)
[atomic-maybe-uninit inline assembly code]: https://github.com/taiki-e/atomic-maybe-uninit/blob/HEAD/src/arch/arm.rs
[portable-atomic no-std test suite]: https://github.com/taiki-e/portable-atomic/tree/HEAD/tests/no-std-qemu
Violets are red,
Roses are blue,
January brought the cold,
And extra coffee too.
--------
Our winner Nouni from @TheElectronWill is the winner at
https://github.com/rust-lang/rust-clippy/pull/16158
> Nouni trying to check whether the new release smells good 👀🐱... It
does!
Definitely it does
<img width="1152" height="1536" alt="image"
src="https://github.com/user-attachments/assets/00c03426-f8b2-43cd-8ea0-ff13ab01413a"
/>
--------
Cats for the next release can be nominated in the comments meow
changelog: none
r? flip1995
Improve error message for assert!() macro in functions returning bool
Detect `assert!()` macro in error messages and provide clearer diagnostics
When `assert!()` is used in a function returning a value, show a message explaining that `assert!()` doesn't return a value, instead of the generic "if may be missing an else clause" error.
Fixesrust-lang/rust#151446
Port `#![crate_type]` to the attribute parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
~~Note that the actual parsing that is used in the compiler session is unchanged, as it must happen very early on; this just ports the validation logic.~~
Also added `// tidy-alphabetical-start` to `check_attr.rs` to make it a bit less conflict-prone
Support slices in type reflection
Tracking issue: rust-lang/rust#146922
This PR adds support for inspecting slices `[T]` through type reflection. It does so by adding the new `Slice` struct + variant, which is very similar to `Array` but without the `len` field:
```rust
pub struct Slice {
pub element_ty: TypeId,
}
```
Here is an example reflecting a slice:
```rust
match const { Type::of::<[u8]>() }.kind {
TypeKind::Slice(slice) => assert_eq!(slice.element_ty, TypeId::of::<u8>()),
_ => unreachable!(),
}
```
In addition to this, I also re-arranged the type info unit tests.
r? @oli-obk
mGCA: Make trait object types with type-level associated consts dyn compatible
Under feature `min_generic_const_args` (mGCA) (rust-lang/rust#132980), render traits with non-parametrized type-level associated constants (i.e., `#[type_const]` ones) dyn compatible but force the user to specify all type-level associated consts in the trait object type via bindings (either directly, via supertrait bounds and/or behind trait aliases) just like associated types, their sibling.
Fixesrust-lang/rust#130300 (feature request).
Fixesrust-lang/rust#136063 (bug).
Fixesrust-lang/rust#137260 (bug).
Fixesrust-lang/rust#137514 (bug).
While I'm accounting for most illegal `Self` references via const projections & params, I'm intentionally ignoring RUST-123140 (and duplicates) in this PR which is to be tackled some other time.
Additional context: Crate `rustc-demangle` had to be updated to fix v0 demangling. I've patched it in PR https://github.com/rust-lang/rustc-demangle/pull/87 which was was released in version 0.1.27 via PR https://github.com/rust-lang/rustc-demangle/pull/88.
The attribute now has a size parameter and sorts differently:
* Explicitly omit size parameter during construction on 23+
* Tolerate alternate sorting in tests
https://github.com/llvm/llvm-project/pull/171712
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#151010 (std: use `ByteStr`'s `Display` for `OsStr`)
- rust-lang/rust#151156 (Add GCC and the GCC codegen backend to build-manifest and rustup)
- rust-lang/rust#151219 (Fixed ICE when using function pointer as const generic parameter)
- rust-lang/rust#151343 (Port some crate level attrs to the attribute parser)
- rust-lang/rust#151463 (add x86_64-unknown-linux-gnuasan to CI)
r? @ghost
Port some crate level attrs to the attribute parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
Ports compiler_builtins, panic_runtime, needs_panic_runtime, profiler_runtime and no_builtins to the attribute parsing infrastructure.
r? @JonathanBrouwer
Fixed ICE when using function pointer as const generic parameter
added bounds check in prohibit_explicit_late_bound_lifetimes to prevent index out of bounds panic when args.args is empty. also regression test here to ensure function pointers in const generics produce proper error messages instead of ICE.
Fixesrust-lang/rust#151186Fixesrust-lang/rust#137084
Add GCC and the GCC codegen backend to build-manifest and rustup
This PR adds the GCC codegen backend, and the GCC (libgccjit) component upon which it depends, to build-manifest, and thus also to (nightly) Rustup. I added both components in a single PR, because one can't work/isn't useful without the other.
Both components are marked as nightly-only and as `-preview`.
As a reminder, the GCC component is special; we need a separate component for every (host, target) compilation pair. This is not something that is really supported by rustup today, so we work around that by creating a separate component/package for each compilation target. So if we want to distribute GCC that can compile from {T1, T2} to {T2, T3}, we will create two separate components (`gcc-T2` and `gcc-T3`), and make both of them available on T1 and T2 hosts.
I tried to reuse the existing structure of `PkgType` in `build-manifest`, but added a target field to the `Gcc` package variant. This required some macro hackery, but at least it doesn't require making larger changes to `build-manifest`.
After this PR lands, unless I messed something up, starting with the following nightly, the following should work:
```bash
rustup +nightly component add rustc-codegen-gcc-preview gcc-x86_64-unknown-linux-gnu-preview
RUSTFLAGS="-Zcodegen-backend=gcc" cargo +nightly build
```
Note that it will work currently only on `x86_64-unknown-linux-gnu`, and only if not cross-compiling.
r? @Mark-Simulacrum
std: use `ByteStr`'s `Display` for `OsStr`
Besides reducing duplication, this also results in formatting parameters like padding, align and fill being respected.
Move bootstrap configuration to library workspace
This creates a new "dist" profile in the standard library which contains configuration for the distributed std artifacts previously contained in bootstrap, in order for a future build-std implementation to use. bootstrap.toml settings continue to override these defaults, as would any RUSTFLAGS provided. I've left some cargo features driven by bootstrap for a future patch.
Unfortunately, profiles aren't expressive enough to express per-target overrides, so [this risc-v example](c8f22ca269/src/bootstrap/src/core/build_steps/compile.rs (L692)) was not able to be moved across. This could go in its own profile which Cargo would have to know to use, and then the panic-abort rustflags overrides would need duplicating again. Doesn't seem like a sustainable solution as a couple similar overrides would explode the number of lines here.
We could use a cargo config in the library workspace for this, but this then would have to be respected by Cargo's build-std implementation and I'm not yet sure about the tradeoffs there.
This patch also introduces a build probe to deal with the test crate's stability which is obviously not ideal, I'm open to other solutions here or can back that change out for now if anyone prefers.
cc @Mark-Simulacrum https://github.com/rust-lang/rfcs/pull/3874
This method was broken by 258ace6, which changed `self.normalized_pos`
to use relative offsets however this method continued to compare against
an absolute offset.
Also adds a regression test for the issue that this method was
originally introduced to fix.
make `simd_insert_dyn` and `simd_extract_dyn` const
For use in `stdarch`. We currently use an equivalent of the fallback body here, but on some targets the intrinsic generate better code.
r? RalfJung
Derive `Default` for `QueryArenas`
There's no need to manually implement Default for this struct, because the fields are all `TypeArena<_>` or `()`, which both implement Default already.
This lets us avoid one occurrence of the `query_if_arena!` macro.
Update compiler/rustc_monomorphize/src/collector.rs
Add FIXME(mgca) comment to potentially re-investigate in the future.
Co-Authored-By: Boxy <rust@boxyuwu.dev>
This fully rewords the diagnostic that was previously only emitted for assoc ty bindings.
That's because it incorrectly called trait aliases *type aliases* and didn't really
make it clear what the root cause is.
The added test used to ICE prior to this change.
I've double-checked that the preexisting test I've modified still ICEs in
nightly-2025-03-29.
We used to lower such bad defaulted const args in trait object types to
`{type error}`; now correctly lower them to `{const error}`.
The added tests used to ICE prior to this change.
Roll bootstrap reviewers for `src/tools/build-manifest`
I honestly don't know who's supposed to be maintaining this tool, but maybe bootstrap? 🤷
r? @Kobzol (maybe)
Simplify lookup of `DepKind` names in duplicate dep node check
This PR simplifies parts of the query system, by removing the `make_dep_kind_name_array!` macro, and removing much of the associated plumbing added by 68fd771bc1.
Instead, we now create a `DEP_KIND_NAMES` constant in `define_dep_nodes!`, and look up names in that instead.
Replace `#[rustc_do_not_implement_via_object]` with `#[rustc_dyn_incompatible_trait]`
Background: `#[rustc_do_not_implement_via_object]` on a trait currently still allows `dyn Trait` to exist (if the trait is otherwise dyn-compatible), it just means that `dyn Trait` does not automatically implement `Trait` via the normal object candidate. For some traits, this means that `dyn Trait` does not implement `Trait` at all (e.g. `Unsize` and `Tuple`). For some traits, this means that `dyn Trait` implements `Trait`, but with different associated types (e.g. `Pointee`, `DiscriminantKind`). Both of these cases can can cause issues with codegen , as seen in https://github.com/rust-lang/rust/issues/148089 (and https://github.com/rust-lang/rust/issues/148089#issuecomment-3447803823 ), because codegen assumes that if `dyn Trait` does not implement `Trait` (including if `dyn Trait<Assoc = T>` does not implement `Trait` with `Assoc == T`), then `dyn Trait` cannot be constructed, so vtable accesses on `dyn Trait` are unreachable, but this is not the case if `dyn Trait` has multiple supertraits: one which is `#[rustc_do_not_implement_via_object]`, and one which we are doing the vtable access to call a method from.
This PR replaces `#[rustc_do_not_implement_via_object]` with `#[rustc_dyn_incompatible_trait]`, which makes the marked trait dyn-incompatible, making `dyn Trait` not well-formed, instead of it being well-formed but not implementing `Trait`. This resolvesrust-lang/rust#148089 by making it not compile.
May fixrust-lang/rust#148615
The traits that are currently marked `#[rustc_do_not_implement_via_object]` are: `Sized`, `MetaSized`, `PointeeSized`, `TransmuteFrom`, `Unsize`, `BikeshedGuaranteedNoDrop`, `DiscriminantKind`, `Destruct`, `Tuple`, `FnPtr`, `Pointee`. Of these:
* `Sized` and `FnPtr` are already not dyn-compatible (`FnPtr: Copy`, which implies `Sized`)
* `MetaSized`
* Removed `#[rustc_do_not_implement_via_object]`. Still dyn-compatible after this change. (Has a special-case in the trait solvers to ignore the object candidate for `dyn MetaSized`, since it `dyn MetaSized: MetSized` comes from the sized candidate that all `dyn Trait` get.)
* `PointeeSized`
* Removed `#[rustc_do_not_implement_via_object]`. It doesn't seem to have been doing anything anyway ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=a395626c8bef791b87a2d371777b7841)), since `PointeeSized` is removed before trait solving(?).
* `Pointee`, `DiscriminantKind`, `Unsize`, and `Tuple` being dyn-compatible without having `dyn Trait: Trait` (with same assoc tys) can be observed to cause codegen issues (https://github.com/rust-lang/rust/issues/148089) so should be made dyn-incompatible
* `Destruct`, `TransmuteFrom`, and `BikeshedGuaranteedNoDrop` I'm not sure if would be useful as object types, but they can be relaxed to being dyn-compatible later if it is determined they should be.
-----
<details> <summary> resolved </summary>
Questions before merge:
1. `dyn MetaSized: MetaSized` having both `SizedCandidate` and `ObjectCandidate`
1. I'm not sure if the checks in compiler/rustc_trait_selection/src/traits/project.rs and compiler/rustc_next_trait_solver/src/solve/assembly/mod.rs were "load-bearing" for `MetaSized` (which is the only trait that was previously `#[rustc_do_not_implement_via_object]` that is still dyn-compatible after this change). Is it fine to just remove them? Removing them (as I did in the second commit) doesn't change any UI test results.
3. IIUC, `dyn MetaSized` could get its `MetaSized` implementation in two ways: the object candidate (the normal `dyn Trait: Trait`) that was supressed by `#[rustc_do_not_implement_via_object]`, and the `SizedCandidate` (that all `dyn Trait` get for `dyn Trait: MetaSized`). Given that `MetaSized` has no associated types or methods, is it fine that these both exist now? Or is it better to only have the `SizedCandidate` and leave these checks in (i.e. drop the second commit, and remove the FIXMEs)?
4. Resolved: the trait solvers special-case `dyn MetaSized` to ignore the object candidate in preference to the sizedness candidate (technically the check is for any `is_sizedness_trait`, but only `MetaSized` gets this far (`Sized` is inherently dyn-incompatible, and `dyn PointeeSized` is ill-formed for other reasons)
4. Diagnostics improvements?
1. The diagnostics are kinda bad. If you have a `trait Foo: Pointee {}`, you now get a note that reads like *Foo* "opted out of dyn-compatbility", when really `Pointee` did that.
2. Resolved: can be improved later
<details> <summary>diagnostic example</summary>
```rs
#![feature(ptr_metadata)]
trait C: std::ptr::Pointee {}
fn main() {
let y: &dyn C;
}
```
```rs
error[E0038]: the trait `C` is not dyn compatible
--> c.rs:6:17
|
6 | let y: &dyn C;
| ^ `C` is not dyn compatible
|
note: for a trait to be dyn compatible it needs to allow building a vtable
for more information, visit <https://doc.rust-lang.org/reference/items/traits.html#dyn-compatibility>
--> /home/zachary/opt_mount/zachary/Programming/rust-compiler-2/library/core/src/ptr/metadata.rs:57:1
|
57 | #[rustc_dyn_incompatible_trait]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ...because it opted out of dyn-compatbility
|
::: c.rs:3:7
|
3 | trait C: std::ptr::Pointee {}
| - this trait is not dyn compatible...
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0038`.
```
</details> </details>
Still investigating "3. `compiler/rustc_hir/src/attrs/encode_cross_crate.rs`: Should `DynIncompatibleTrait` attribute be encoded cross crate?"
missing colon after the compile-flags directive
This is a trivial issue as the title suggests. All tests in the `ui` test suite have a colon after the `compile-flags` directive except for this one.
`c_variadic`: impl `va_copy` and `va_end` as Rust intrinsics
tracking issue: https://github.com/rust-lang/rust/issues/44930
Implement `va_copy` as (the rust equivalent of) `memcpy`, which is the behavior of all current LLVM targets. By providing our own implementation, we can guarantee its behavior. These guarantees are important for implementing c-variadics in e.g. const-eval.
Discussed in [#t-compiler/const-eval > c-variadics in const-eval](https://rust-lang.zulipchat.com/#narrow/channel/146212-t-compiler.2Fconst-eval/topic/c-variadics.20in.20const-eval/with/565509704).
I've also updated the comment for `Drop` a bit. The background here is that the C standard requires that `va_end` is used in the same function (and really, in the same scope) as the corresponding `va_start` or `va_copy`. That is because historically `va_start` would start a scope, which `va_end` would then close. e.g.
https://softwarepreservation.computerhistory.org/c_plus_plus/cfront/release_3.0.3/source/incl-master/proto-headers/stdarg.sol
```c
#define va_start(ap, parmN) {\
va_buf _va;\
_vastart(ap = (va_list)_va, (char *)&parmN + sizeof parmN)
#define va_end(ap) }
#define va_arg(ap, mode) *((mode *)_vaarg(ap, sizeof (mode)))
```
The C standard still has to consider such implementations, but for Rust they are irrelevant. Hence we can use `Clone` for `va_copy` and `Drop` for `va_end`.
Only run finalizers of accepted attributes
Locally this had insanely good perf, but lets see what reality thinks about this
r? @jdonszelmann
Attribute parsing consists of two stages:
- All attribute are "accepted" by one or more parsers, which means the unparsed attribute is parsed, information about it is stored in the attr parser struct
- After all attributes are parsed, we "finalize" all parsers, producing a single parsed attribute representation from the parser struct.
This two-stage process exist so multiple attributes can get merged into one parser representation. For example if you have two repr attributes `#[repr(C)]` `#[repr(packed)]` it will only produce one parsed `Repr` attribue.
The dumb thing we did was we would "finalize" all parsers, even the ones that never accepted an attribute. This PR only calls finalize on the parsers that accepted at least one attribute.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#151216 ([rustdoc] Make popover menus content scrollable on mobile devices)
- rust-lang/rust#151373 (Fix an ICE on transmute goals with placeholders in `param_env`)
- rust-lang/rust#151399 (Generate error delegation when delegation is not resolved)
- rust-lang/rust#151406 (Use version 1.93.0 in `RELEASES.md` instead of 1.93)
- rust-lang/rust#151410 (Fixes for LLVM 22 compatibility)
- rust-lang/rust#151415 (chore: Remove redundant conversion)
- rust-lang/rust#151418 (Avoid pulling in unicode when calling io::Error::kind)
r? @ghost
Removes the attribute from `MetaSized` and `PointeeSized`, with a special case in the trait solvers for `MetaSized`.
`dyn MetaSized` is a perfectly cromulent type, and seems to only have had #[rustc_do_not_implement_via_object] so the builtin object
candidate does not overlap with the builtin MetaSized impl that all `dyn` types get.
Resolves this with a special case by checking `is_sizedness_trait` where the trait solvers previously checked `implement_via_object`.
`dyn PointeeSized` alone is rejected for other reasons (since `dyn PointeeSized` is considered to have no principal trait because `PointeeSized`
is removed at an earlier stage of the compiler), but `(dyn PointeeSized + Send)` is valid and equivalent to `dyn Send`.
Add suggestions from code review
Update compiler/rustc_trait_selection/src/traits/dyn_compatibility.rs and tests
Co-authored-by: lcnr <rust@lcnr.de>
Fixes for LLVM 22 compatibility
This includes three fixes for LLVM 22 compatibility:
* Update the AMDGPU data layout.
* Update AVX512 target feature handling. `evex512` is no longer used and `avx10.[12]-512` are now just `avx10.[12]`, matching the Rust feature name.
* Strip address space casts when emitting lifetime intrinsics. These are now required to directly work on the alloca.
r? @cuviper
Generate error delegation when delegation is not resolved
This PR is a part of the delegation feature rust-lang/rust#118212 and fixesrust-lang/rust#151356.
r? @petrochenkov
Fix an ICE on transmute goals with placeholders in `param_env`
Fixesrust-lang/rust#151300
The next solver short-circuits `consider_builtin_transmute_candidate` when the goal contains non-region placeholders, since `rustc_transmute` does not support type parameters.
However, this check should likely be refined to apply only to the predicate itself: excess bounds with type params in the param env can cause the goal to be rejected even when its predicate trivially holds.
r? types
This uses a build probe to figure out the current toolchain version -
the only alternative to this is bespoke logic in Cargo to tell `test`
when the toolchain is stable/unstable.
The behaviour should be the same as when using
`CFG_DISABLE_UNSTABLE_FEATURES` unless an arbitrary channel is provided
to bootstrap, which I believe necessitates a fork anyway.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#147611 (Stabilize `-Zremap-path-scope`)
- rust-lang/rust#149058 (FCW Lint when using an ambiguously glob imported trait)
- rust-lang/rust#149644 (Create x86_64-unknown-linux-gnuasan target which enables ASAN by default)
- rust-lang/rust#150524 (Test that -Zbuild-std=core works on a variety of profiles)
- rust-lang/rust#151394 (Fix typos: 'occured' -> 'occurred' and 'non_existant' -> 'non_existent')
- rust-lang/rust#151396 (`rustc_queries!`: Don't push the `(cache)` modifier twice)
r? @ghost
As Intel has walked back on the existence of AVX 10.1-256, LLVM
no longer uses evex512 and avx-10.n-512 are now avx-10.n instead,
so we can skip all the special handling on LLVM 22.
Create x86_64-unknown-linux-gnuasan target which enables ASAN by default
As suggested, in order to distribute sanitizer instrumented standard libraries without introducing new rustc flags, this adds a new dedicated target. With the target, we can distribute the instrumented standard libraries through a separate rustup component.
> A tier 2 target must have value to people other than its maintainers. (It may still be a niche target, but it must not be exclusively useful for an inherently closed group.)
The target is useful to anyone who wants to use ASAN with a stable compiler or the ease to not have to recompiled all standard libraries for full coverage.
> A tier 2 target must have a designated team of developers (the “target maintainers”) available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.
> * The target maintainers should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance documentation of the target.
I pledge myself and the folks from the Exploit Mitigations Project Group (rcvalle@ & 1c3t3a@) as target maintainers to fix target-specific issues and educate the Rust community about their use.
> The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target.
Understood. The target should not have negative impact for anyone not using it.
> The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target. If at all possible, this documentation should show how to run Rust programs and tests for the target using emulation, to allow anyone to do so. If the target cannot be feasibly emulated, the documentation should explain how to obtain and work with physical hardware, cloud systems, or equivalent.
`src/doc/rustc/src/platform-support/x86_64-unknown-linux-gnuasan.md` should provide the necessary documentation on how to build the target or compile programs with it. In the way the target can be emulated it should not differ from the tier 1 target `x86_64-unknown-linux-gnu`.
> The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.
The baseline expectation mirror `x86_64-unknown-linux-gnu`.
> If introducing a new tier 2 or higher target that is identical to an existing Rust target except for the baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar, then the proposed target must document to the satisfaction of the approving teams why the specific difference in baseline expectations provides sufficient value to justify a separate target.
> * Note that in some cases, based on the usage of existing targets within the Rust community, Rust developers or a target’s maintainers may wish to modify the baseline expectations of a target, or split an existing target into multiple targets with different baseline expectations. A proposal to do so will be treated similarly to the analogous promotion, demotion, or removal of a target, according to this policy, with the same team approvals required.
> * For instance, if an OS version has become obsolete and unsupported, a target for that OS may raise its baseline expectations for OS version (treated as though removing a target corresponding to the older versions), or a target for that OS may split out support for older OS versions into a lower-tier target (treated as though demoting a target corresponding to the older versions, and requiring justification for a new target at a lower tier for the older OS versions).
This has been outlined sufficiently. We should not enabled ASAN in the default target and are therefore creating a new tier 2 target to bridge the gap until `build-std` stabilized.
> Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.
> * The right approach to handling a missing feature from a target may depend on whether the target seems likely to develop the feature in the future. In some cases, a target may be co-developed along with Rust support, and Rust may gain new features on the target as that target gains the capabilities to support those features.
> * As an exception, a target identical to an existing tier 1 target except for lower baseline expectations for the OS, CPU, or similar, may propose to qualify as tier 2 (but not higher) without support for std if the target will primarily be used in no_std applications, to reduce the support burden for the standard library. In this case, evaluation of the proposed target’s value will take this limitation into account.
All of std that is supported by `x86_64-unknown-linux-gnu` is also supported.
> The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. (This requirement does not apply to arbitrary security enhancements or mitigations provided by code generation backends, only to those properties needed to ensure safe Rust code cannot cause undefined behavior or other unsoundness.) If this requirement does not hold, the target must clearly and prominently document any such limitations as part of the target’s entry in the target tier list, and ideally also via a failing test in the testsuite. The Rust compiler team must be satisfied with the balance between these limitations and the difficulty of implementing the necessary features.
> * For example, if Rust relies on a specific code generation feature to ensure that safe code cannot overflow the stack, the code generation for the target should support that feature.
> * If the Rust compiler introduces new safety properties (such as via new capabilities of a compiler backend), the Rust compiler team will determine if they consider those new safety properties a best-effort improvement for specific targets, or a required property for all Rust targets. In the latter case, the compiler team may require the maintainers of existing targets to either implement and confirm support for the property or update the target tier list with documentation of the missing property.
The entire point is to have more security instead of less ;) The safety properties provided are already present in the compiler, just not enabled by default.
> If the target supports C code, and the target has an interoperable calling convention for C code, the Rust target must support that C calling convention for the platform via extern "C". The C calling convention does not need to be the default Rust calling convention for the target, however.
Understood.
> The target must build reliably in CI, for all components that Rust’s CI considers mandatory.
Understood and the reason for introducing the tier 2 target.
> The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional “hello world” program, ./x.py test --no-run, or equivalent “smoke tests”. In particular, this requirement may apply if the target builds host tools, or if the tests in question provide substantial value via early detection of critical problems.
Understood.
> Building the target in CI must not take substantially longer than the current slowest target in CI, and should not substantially raise the maintenance burden of the CI infrastructure. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account.
Understood.
> Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 targets should not require using the target as the host for builds, even if the target supports host tools.
Understood. No need to use this target as the host (no benefit of having ASAN enabled for compiling).
> In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target and redistributing any resulting compiled binaries (e.g. built libraries, host tools if any) must not impose any onerous license requirements on any members of the Rust project, including infrastructure team members and those operating CI systems. This is a subjective requirement, to be evaluated by the approving teams.
> * As an exception to this, if the target’s primary purpose is to build components for a Free and Open Source Software (FOSS) project licensed under “copyleft” terms (terms which require licensing other code under compatible FOSS terms), such as kernel modules or plugins, then the standard libraries for the target may potentially be subject to copyleft terms, as long as such terms are satisfied by Rust’s existing practices of providing full corresponding source code. Note that anything added to the Rust repository itself must still use Rust’s standard license terms.
Understood, no legal differences between this target and `x86_64-unknown-linux-gnu`.
> Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on tests failing for the target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding the PR breaking tests on a tier 2 target, unless they have opted into such messages.
> * Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
Understood.
> The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.
Understood.
> All requirements for tier 3 apply.
Requirements for tier 3 are listed below.
> A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)
I pledge to do my best maintaining it and we can also include the folks from the Exploit Mitigations Project Group (rcvalle@ & 1c3t3a@).
> Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
We've chosen `x86_64-unknown-linux-gnuasan` as the name which was suggested on [#t-compiler/major changes > Create new Tier 2 targets with sanitizers… compiler-team#951 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Create.20new.20Tier.202.20targets.20with.20sanitizers.E2.80.A6.20compiler-team.23951/near/564482315).
> Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
There should be no confusion, it's clear that it's the original target with ASAN enabled.
> If possible, use only letters, numbers, dashes and underscores for the name. Periods (.) are known to cause issues in Cargo.
Only letters, numbers and dashes used.
> Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
There are no unusual requirements to build or use it. It's the original `x86_64-unknown-linux-gnu` target with ASAN enabled as a default sanitizer.
> The target must not introduce license incompatibilities.
There are no license implications.
> Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
Given, by reusing the existing ASAN code.
> The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
There are no new dependencies/features required.
> Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
It's using open source tools only.
> "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.
There are no such terms present.
> Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
Understood.
> This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.
Understood.
> Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.
The goal is to have ASAN instrumented standard library variants of the existing `x86_64-unknown-linux-gnu` target, so all should be present.
> The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.
I think the explanation in platform support doc is enough to make this aspect clear.
> Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.
Understood.
> Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
Understood.
> In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.
I don't believe this PR is affected by this.
> Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target. (Having support in a fork of the backend is not sufficient, it must be upstream.)
The target should work on all rustc versions that correctly compile for `x86_64-unknown-linux-gnu`.
FCW Lint when using an ambiguously glob imported trait
Related to rust-lang/rust#147992.
Report a lint when using an ambiguously glob import trait, this is a FCW because this should not be allowed.
r? @petrochenkov
Stabilize `-Zremap-path-scope`
# Stabilization report of `--remap-path-scope`
## Summary
RFC 3127 trim-paths aims to improve the current status of sanitizing paths emitted by the compiler via the `--remap-path-prefix=FROM=TO` command line flag, by offering a profile setting named `trim-paths` in Cargo to sanitize absolute paths introduced during compilation that may be embedded in the compiled binary executable or library.
As part of that RFC the compiler was asked to add the `--remap-path-scope` command-line flag to control the scoping of how paths get remapped in the resulting binary.
Tracking:
- https://github.com/rust-lang/rust/issues/111540
### What is stabilized
The rustc `--remap-path-scope` flag is being stabilized by this PR. It defines which scopes of paths should be remapped by `--remap-path-prefix`.
This flag accepts a comma-separated list of values and may be specified multiple times, in which case the scopes are aggregated together.
The valid scopes are:
- `macro` - apply remappings to the expansion of `std::file!()` macro. This is where paths in embedded panic messages come from
- `diagnostics` - apply remappings to printed compiler diagnostics
- `debuginfo` - apply remappings to debug informations
- `coverage` - apply remappings to coverage informations
- `object` - apply remappings to all paths in compiled executables or libraries, but not elsewhere. Currently an alias for `macro,coverage,debuginfo`.
- `all` (default) - an alias for all of the above, also equivalent to supplying only `--remap-path-prefix` without `--remap-path-scope`.
#### Example
```sh
# With `object` scope only the build outputs will be remapped, the diagnostics won't be remapped.
rustc --remap-path-prefix=$(PWD)=/remapped --remap-path-scope=object main.rs
```
### What isn't stabilized
None of the Cargo facility is being stabilized in this stabilization PR, only the `--remap-path-scope` flag in `rustc` is being stabilized.
## Design
### RFC history
- [RFC3127 - trim-paths](https://rust-lang.github.io/rfcs/3127-trim-paths.html)
### Answers to unresolved questions
> What questions were left unresolved by the RFC? How have they been answered? Link to any relevant lang decisions.
There are no unresolved questions regarding `--remap-path-scope`.
(The tracking issue list a bunch of unresolved questions but they are for `--remap-path-prefix` or the bigger picture `trim-paths` in Cargo and are not related the functionality provided by `--remap-path-scope`.)
### Post-RFC changes
The RFC described more scopes, in particularly regarding split debuginfo. Those scopes where removed after analysis by `michaelwoerister` of all the possible combinations in https://github.com/rust-lang/rust/issues/111540#issuecomment-1994010274.
### Nightly extensions
There are no nightly extensions.
### Doors closed
We are committing to having to having a flag that control which paths are being remapped based on a "scope".
## Feedback
### Call for testing
> Has a "call for testing" been done? If so, what feedback was received?
No call for testing has been done per se but feedback has been received on both the rust-lang/rust and rust-lang/cargo tracking issue.
The feedback was mainly related to deficiencies in *our best-effort* `--remap-path-prefix` implementation, in particular regarding linkers added paths, which does not change anything for `--remap-path-scope`.
### Nightly use
> Do any known nightly users use this feature? Counting instances of `#![feature(FEATURE_NAME)]` on GitHub with grep might be informative.
Except for Cargo unstable `trim-paths` there doesn't appear any committed use [on GitHub](https://github.com/search?q=%22--remap-path-scope%22+NOT+path%3A%2F%5Esrc%5C%2Fcargo%5C%2Fcore%5C%2Fcompiler%5C%2F%2F+NOT+path%3A%2F%5Etext%5C%2F%2F+NOT+path%3A%2F%5Erust%5C%2Fsrc%5C%2Fdoc%5C%2Funstable-book%5C%2Fsrc%5C%2Fcompiler-flags%5C%2F%2F+NOT+path%3A%2F%5Esrc%5C%2Fdoc%5C%2Funstable-book%5C%2Fsrc%5C%2Fcompiler-flags%5C%2F%2F+NOT+path%3A%2F%5Ecollector%5C%2Fcompile-benchmarks%5C%2Fcargo-0%5C.87%5C.1%5C%2Fsrc%5C%2Fcargo%5C%2Fcore%5C%2Fcompiler%5C%2F%2F&type=code).
## Implementation
### Major parts
- b3f8586fb1/compiler/rustc_session/src/config.rs (L1373-L1384)
- b3f8586fb1/compiler/rustc_session/src/session.rs (L1526)
- b3f8586fb1/compiler/rustc_span/src/lib.rs (L352-L372)
### Coverage
- [`tests/run-make/split-debuginfo/rmake.rs`](9725c4baac/tests/run-make/split-debuginfo/rmake.rs (L7))
- [`tests/ui/errors/remap-path-prefix.rs`](9725c4baac/tests/ui/errors/remap-path-prefix.rs (L4))
- [`tests/ui/errors/remap-path-prefix-macro.rs`](9725c4baac/tests/ui/errors/remap-path-prefix-macro.rs (L1-L4))
- [`tests/run-make/remap-path-prefix-dwarf/rmake.rs
`](9725c4baac/tests/run-make/remap-path-prefix-dwarf/rmake.rs)
- [`tests/run-make/remap-path-prefix/rmake.rs`](9725c4baac/tests/run-make/remap-path-prefix/rmake.rs)
- [`tests/ui/errors/remap-path-prefix-diagnostics.rs`](9725c4baac/tests/ui/errors/remap-path-prefix-diagnostics.rs)
### Outstanding bugs
> What outstanding bugs involve this feature? List them. Should any block the stabilization? Discuss why or why not.
There are no outstanding bugs regarding `--remap-path-scope`.
### Outstanding FIXMEs
> What FIXMEs are still in the code for that feature and why is it OK to leave them there?
There are no FIXME regarding `--remap-path-scope` in it-self.
### Tool changes
> What changes must be made to our other tools to support this feature. Has this work been done? Link to any relevant PRs and issues.
- rustdoc (both JSON, HTML and doctest)
- `rustdoc` has support for `--remap-path-prefix`, it should probably also get support for `--remap-path-scope`, although rustdoc maybe want to adapt the scopes for it's use (replace `debuginfo` with `documentation` for example).
## History
> List issues and PRs that are important for understanding how we got here.
- https://github.com/rust-lang/rust/pull/115214
- https://github.com/rust-lang/rust/pull/122450
- https://github.com/rust-lang/rust/pull/139550
- https://github.com/rust-lang/rust/pull/140716
## Acknowledgments
> Summarize contributors to the feature by name for recognition and so that those people are notified about the stabilization. Does anyone who worked on this *not* think it should be stabilized right now? We'd like to hear about that if so.
- @cbeuw
- @michaelwoerister
- @weihanglo
- @Urgau
@rustbot labels +T-compiler +needs-fcp +F-trim-paths
r? @davidtwco
Add a new method `references_only_ty_error` to the `Ty` implementation
to determine if a type contains only type errors, ignoring const and
lifetime errors. Enhance test suite for const generic method resolution.
changelog: [`manual_checked_ops`]: new lint suggesting `checked_div`
instead of manual zero checks before unsigned division
Part of the initiative described in rust-lang/rust-clippy#12894.
As suggested, in order to distribute sanitizer instrumented standard
libraries without introducing new rustc flags, this adds a new dedicated
target. With the target, we can distribute the instrumented standard
libraries through a separate rustup component.
On LoongArch targets, `-Cdirect-access-external-data` defaults to `no`.
Since copy relocations are not supported, `dso_local` is not emitted
under `-Crelocation-model=static`, unlike on other targets.
rustdoc: Fix ICE when deprecated note is not resolved on the correct `DefId`
Supersedes https://github.com/rust-lang/rust/pull/151237.
Follow-up of rust-lang/rust#151120.
The `span` overlapping approach wasn't good enough so instead we now check if the reexport itself has the `deprecated` attribute, and if so, we resolve the path to the reexport `DefId`, otherwise we resolve it on the reexported item's `DefId`.
cc @Zalathar
r? @lolbinarycat
Add new "hide deprecated items" setting in rustdoc
This PR adds a new JS setting which allows the JS to hide deprecated items. This is especially useful for crates like `std` which accumulates deprecated items but never removes them.
Nicely enough, the "deprecation" information was already in the search index, meaning I didn't need to change anything there. Before this PR, it was only used to make the deprecated items rank lower. Well now it's also used to generate an extra CSS class, allowing the JS setting to work.
This is taking over https://github.com/rust-lang/rust/pull/149551.
This feature got approved by the rustdoc team in the [meeting of december](https://rust-lang.zulipchat.com/#narrow/channel/393423-t-rustdoc.2Fmeetings/topic/2025-12-08/near/562553156).
You can give it a try [here](https://rustdoc.crud.net/imperio/hide-deprecated-items/foo/index.html).
r? @lolbinarycat
Add scalar support for offload
This PR adds scalar support to the offload feature. The scalar management has two main parts:
On the host side, each scalar arg is casted to `ix` type, zero extended to `i64` and passed to the kernel like that.
On the device, the each scalar arg (`i64` at that point), is truncated to `ix` and then casted to the original type.
r? @ZuseZ4
Add dist step for Enzyme
Now that Enzyme can be distributed as a separate dylib outside libLLVM.so, we can create a dist step for it. This is the bulk of the work required to make it distributable through rustup, once CI works and we check that the built component works locally, we can add it to Rustup through the manifest.
Note that this PR does not enable Enzyme distribution in CI yet, it just adds the dist step.
r? @ZuseZ4
try-job: dist-x86_64-linux
coverage: Sort the expansion tree to help choose a single BCB for child expansions
This PR is another incremental step on the road towards proper coverage instrumentation of expansion regions.
When creating coverage mappings for each relevant span in a function body, the current implementation also needs to do a separate tree traversal for each child expansion (e.g. macro calls like `println!("foo")`), in order to associate a single control-flow point (BCB) with that macro call's span.
This PR changes things so that we now keep track of the “minimum” and ”maximum” BCB associated with each node in the expansion tree, which makes it much easier for the parent node to get a single BCB (min or max) for each of its child expansions.
In order to make this (relatively) easy, we first need to sort the tree nodes into depth-first order. Once that's taken care of, we can iterate over all the nodes in reverse order, knowing that each node's children will have been visited before visiting the node itself.
compiler: upgrade to hashbrown 0.16.1
See also rust-lang/rust#135634, rust-lang/rust#149159, and rust-lang/hashbrown#662.
This includes an in-tree upgrade of `indexmap` as well, which uses the
new `HashTable` buckets API internally, hopefully impacting performance
for the better.
And finally, we can remove `#[rustc_unsafe_specialization_marker]` on `Copy`!
cc @joboet
r? @Amanieu
Only `==` (and thus `!=`) are supposed to be commutative according to
Rust's documentation. Do not make assumptions about other operators
whose meaning may depend on the types on which they apply. However,
special-case operators known to be commutative for primitive types such
as addition or multiplication.
changelog: [`if_same_then_else`]: do not consider binary operators
commutative by default
Fixesrust-lang/rust-clippy#16416
Remove `DiagMessage::Translated` in favour of `DiagMessage::Str`
This variant did not seem to be meaningfully different from `DiagMessage::Str`.
Am I missing something or was this just an oversight?
r? @davidtwco
THIR patterns: Use `ty::Value` in more places throughout `const_to_pat`
This PR changes `ConstToPat::valtree_to_pat` to take a `ty::Value` instead of separate type and valtree arguments, and propagates that change throughout other parts of the overall `const_to_pat` implementation.
The biggest under-the-hood change is that instead of combining valtrees from the constant with child types from the parent type, we now just rely on the types already embedded in children of the valtree.
I'm not *entirely* sure that this is correct, but it doesn't seem to cause any failures in the test suite, and from what I can tell the old way was a holdover from a time when the types weren't readily available from the value side.
---
My ulterior motive for this cleanup is that I'm hoping to eventually add some extra data to `thir::PatKind::Const`, which will be a little easier if creation of that `PatKind::Const` doesn't have to assemble a `ty::Value` from component parts.
HIR typeck cleanup: clarify and re-style `check_expr_unop`
Two small cleanups:
- The `oprnd_t` variable was previously used both for the type of unary operators' operands and for the type of the operator expression as a whole. I found this confusing, so I've changed it to only be used for the operand type. This also allowed for removing some negations from `if` conditions.
- I did a bit of re-styling in the second commit to remove some indentation levels, which also means fewer things have to be spread across multiple lines. This part is more to-taste; I'd be fine dropping it if it doesn't actually help.
Do not recover from `Trait()` if generic list is unterminated
If we encounter `fn foo<T: Trait()`, the recovery logic would it as if `Trait` was intended to use the Fn-like trait syntax, but if we don't know for certain that we've parsed a full trait bound (`fn foo<T: Trait()>`), we bail from the recovery as more likely there could have been a missing closing `>` and the `(` corresponds to the start of the fn parameter list.
Fixrust-lang/rust#141436.
Support pointers in type reflection
Tracking issue: rust-lang/rust#146922
This PR adds support for inspecting pointers `*const T` and `*mut T` through type reflection. It does so by adding the new `Pointer` struct + variant:
```rust
pub struct Pointer {
/// The type of the value being pointed to.
pub ty: TypeId,
/// Whether this pointer is mutable or not.
pub mutable: bool,
}
```
This can be gathered using `Type::of`, for example:
```rust
match const { Type::of::<*const u8>() }.kind {
TypeKind::Pointer(pointer) => {
assert_eq!(pointer.ty, TypeId::of::<u8>());
assert!(!pointer.mutable);
}
_ => unreachable!(),
}
```
Simplify some literal-value negations with `u128::wrapping_neg`
- Calling `overflowing_neg` and then discarding the overflow bit is the same as just calling `wrapping_neg`.
- Casting to `u128` to `i128`, negating, and then casting back produces the same result as just performing an unsigned `wrapping_neg`.
There should be no actual change to compiler behaviour.
std: implement `sleep_until` on Apple platforms
On Apple platforms, `nanosleep` is internally [implemented](55b54c0a0c/gen/nanosleep.c (L281)) using `mach_wait_until`, a function that waits until a deadline specified in terms of `mach_absolute_time`. Since `mach_wait_until` is [public](f6217f891a/osfmk/mach/mach_time.h (L50-L51))[^1], we can use it to implement `sleep_until` by converting `Instant`s (which are measured against `CLOCK_UPTIME_RAW`, which is equivalent to `mach_absolute_time`) into `mach_absolute_time` values.
Related tracking issue: https://github.com/rust-lang/rust/issues/113752
[^1]: It's badly documented, but it's defined in the same header as `mach_absolute_time`, which `std` used to use for `Instant` before rust-lang/rust#116238.
remote-test-server: Fix header in batch mode
In https://github.com/rust-lang/rust/pull/119999, the length field of the header was changed from 4 bytes to 8. One of the headers in `batch_copy` was missed though, so it sends the wrong size. Fix by switching to `create_header` in that spot too.
rustc_errors: Add (heuristic) Syntax Highlighting for `rustc --explain`
This PR adds a feature that enables `rustc --explain <error>` to have syntax highlighted code blocks. Due to performance, size and complexity constraints, the highlighter is very heuristc, relying on conventions for capitalizations and such to infer what an identifier represents. The details for the implementation are specified below.
# Changes
1. Change `term::entrypoint` to `term::entrypoint_with_formatter`, which takes an optional third argument, which is a function pointer to a formatter. ([compiler/rustc_errors/src/markdown/mod.rs](https://github.com/rust-lang/rust/compare/main...JayanAXHF:rust:rustc_colored_explain?expand=1#diff-a6e139cadbc2e6922d816eb08f9e2c7b48304d09e6588227e2b70215c4f0725c))
2. Change `MdStream::write_anstream_buf` to be a wrapper around a new function, `MdStream::write_anstream_buf_with_formatter`, which takes a function pointer to a formatter. ([compiler/rustc_errors/src/markdown/mod.rs](https://github.com/rust-lang/rust/compare/main...JayanAXHF:rust:rustc_colored_explain?expand=1#diff-a6e139cadbc2e6922d816eb08f9e2c7b48304d09e6588227e2b70215c4f0725c))
3. Change [`compiler/rustc_driver_impl/src/lib.rs`](https://github.com/rust-lang/rust/compare/main...JayanAXHF:rust:rustc_colored_explain?expand=1#diff-39877a2556ea309c89384956740d5892a59cef024aa9473cce16bbdd99287937) to call `MdStream::write_anstream_buf_with_formatter` instead of `MdStream::write_anstream_buf`.
4. Add a `compiler/rustc_driver_impl/src/highlighter.rs` file, which contains the actual syntax highlighter.
# Implementation Details
1. The highlighter starts from the `highlight` function defined in `compiler/rustc_driver_impl/src/highlighter.rs`. It creates a new instance of the `Highlighter` struct, and calls its `highlight_rustc_lexer` function to start highlighting.
2. The `highlight_rustc_lexer` function uses `rustc_lexer` to lex the code into `Token`s. `rustc_lexer` was chosen since it preserves the newlines after scanning.
3. Based on the kind of token (`TokenKind`), we color the corresponding lexeme.
## Highlighter Implementation
### Identifiers
1. All identifiers that match a (non-exhaustive and minimal) list of keywords are coloured magenta.
2. An identifier that begins with a capital letter is assumed as a type. There is no distinction between a `Trait` and a type, since that would involve name resolution, and the parts of `rustc` that perform name resolution on code do not preserve the original formatting. (An attempt to use `rustc_parse`'s lexer and `TokenStream` was made, which was then printed with the pretty printer, but failed to preserve the formatting and was generally more complex to work with)
3. An identifier that is immediately followed by a parenthesis is recognized as a function identifier, and coloured blue.
## Literals
5. A `String` literal (or its corresponding `Raw`, `C` and `Byte` versions) is colored green.
6. All other literals are colored bright red (orange-esque)
## Everything Else
Everything else is colored bright white and dimmed, to create a grayish colour.
---
# Demo
<img width="1864" height="2136" alt="image" src="https://github.com/user-attachments/assets/b17d3a71-e641-4457-be85-5e5b1cea2954" />
<caption> Command: <code>rustc --explain E0520</code> </caption>
---
This description was not generated by an LLM (:p)
cc: @bjorn3
Remove the diagnostic lints
Removes the `untranslatable_diagnostic` and `diagnostic_outside_of_impl` lints
These lints are allowed for a while already. Per https://github.com/rust-lang/compiler-team/issues/959, we no longer want to enforce struct diagnostics for all usecases, so this is no longer useful.
r? @Kivooeo
I recommend reviewing commit by commit (also feel free to wait with reviewing until the MCP is accepted)
@rustbot +S-blocked
Blocked by https://github.com/rust-lang/compiler-team/issues/959
Ignore `#[doc(hidden)]` items when computing trimmed paths for printing
The `trimmed_def_paths` query examines all items in the current crate, and all pub items in immediate-dependency crates (including the standard library), to see which item names are unique and can therefore be printed unambiguously as a bare name without a module path.
Currently that query has no special handling for `#[doc(hidden)]` items, which has two consequences:
- Hidden names can be considered unique, and will therefore be printed without a path, making it hard to find where that name is defined (since it normally isn't listed in documentation).
- Hidden names can conflict with visible names that would otherwise be considered unique, causing diagnostics to mysteriously become more verbose based on internal details of other crates.
This PR therefore makes the `trimmed_def_paths` query ignore external-crate items that are `#[doc(hidden)]`, along with their descendants.
As a result, hidden item names are never considered unique for trimming, and no longer interfere with visible item names being considered unique.
---
- Fixes https://github.com/rust-lang/rust/issues/148387.
Now, only `call_span` is replaced, so the receiver is not a part of the
diff. This also removes the need to create a snippet for the receiver.
changelog: [`unnecessary_sort_by`]: reduce suggestion diffs
This commit adds a heuristics-based syntax highlighter for the `rustc
--explain` command. It uses `rsutc_lexer`'s lexer to parse input in
tokens, and matches on them to determine their color.
compiler: Temporarily re-export `assert_matches!` to reduce stabilization churn
https://github.com/rust-lang/rust/pull/137487 proposes to stabilize `feature(assert_matches)`, while simultaneously moving the `assert_matches!` and `debug_assert_matches!` macros out of the `std::assert_matches` submodule and exporting them directly from the `std` crate root instead.
Unfortunately, that moving step would cause a lot of `cfg(bootstrap)` churn and noise in the compiler, because the compiler imports and uses those macros in dozens of places.
This PR therefore aims to reduce the overall compiler churn, by temporarily adjusting the compiler to always use `assert_matches!` via a re-export from `rustc_data_structures`. That way, the stabilization itself would only need to add `cfg(bootstrap)` to that single re-export (plus the associated `#![feature(assert_matches)]` attributes), greatly reducing the immediate impact on the compiler.
Once `assert_matches!` is stable in the stage0 bootstrap compiler, we can go back and delete the re-export, and adjust the rest of the compiler to import directly from `std` instead.
Generate openmp metadata
LLVM has an openmp-opt pass, which is part of the default O3 pipeline.
The pass bails if we don't have a global called openmp, so let's generate it if people enable our experimental offload feature. openmp is a superset of the offload feature, so they share optimizations.
In follow-up PRs I'll start verifying that LLVM optimizes Rust the way we want it.
r? compiler
New MIR Pass: SsaRangePropagation
As an alternative to https://github.com/rust-lang/rust/pull/150192.
Introduces a new pass that propagates the known ranges of SSA locals.
We can know the ranges of SSA locals at some locations for the following code:
```rust
fn foo(a: u32) {
let b = a < 9;
if b {
let c = b; // c is true since b is whitin the range [1, 2)
let d = a < 8; // d is true since b whitin the range [0, 9)
}
}
```
This PR only implements a trivial range: we know one value on switch, assert, and assume.
For inputs smaller than 32 bytes, use usize-at-a-time processing
instead of calling the SSE2 function. This avoids function call
overhead from #[target_feature(enable = "sse2")] which prevents
inlining.
Also moves CHUNK_SIZE to module level so it can be shared between
is_ascii and is_ascii_sse2.
Port rustc allocator attributes to attribute parser
Tracking issue: rust-lang/rust#131229
Made a new file since i saw this pattern for `rustc_dump.rs`
Very simple attributes so felt like I can do them all in one PR
r? @JonathanBrouwer
fix: thread creation failed on the wasm32-wasip1-threads target.
wasm32-wasip1-threads target cannot create thread since nightly-2026-01-16.
This commit (c1bcae0638) broken it.
It in https://github.com/rust-lang/rust/pull/151016
This pull-request fix that issue.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#150767 (Allow invoking all help options at once)
- rust-lang/rust#150886 (Added mGCA related tests)
- rust-lang/rust#151245 (Explicitly list crate level attrs)
- rust-lang/rust#151268 (Fix ICE on inconsistent import resolution with macro-attributed extern crate)
- rust-lang/rust#151275 (Normalize type_const items even with feature `generic_const_exprs`)
- rust-lang/rust#151288 (Use `find_attr` instead of `attr::contains_name` in `lower_const_item_rhs`)
- rust-lang/rust#151321 (Port #![no_main] to the attribute parser.)
r? @ghost
Use `find_attr` instead of `attr::contains_name` in `lower_const_item_rhs`
Fixesrust-lang/rust#151250
`attr::contains_name` uses `AttributeExt::name()` to filter, but for `hir::Attribute::Parsed`, this method will return `None`, and then `attr::contains_name` will return `false` here. So that the previous logic cannot work as expected.
r? @BoxyUwU
Normalize type_const items even with feature `generic_const_exprs`
Fixesrust-lang/rust#151251
With feature `generic_const_exprs` enabled, consts with `#[type_const]` won't be normalized even if they need. Then ICE happens when CTFE tries to evaluate such const without body.
Fix this by normalizing such consts even with feature `generic_const_exprs` enabled.
r? @BoxyUwU
Fix ICE on inconsistent import resolution with macro-attributed extern crate
Fixesrust-lang/rust#151213 using issue_145575_hack_applied in the same way as in rust-lang/rust#149860.
Allow invoking all help options at once
Implements rust-lang/rust#150442
Help messages are printed in the order they are invoked, but only once (e.g. `--help -C help --help` prints regular help then codegen help).
Lint groups (`-Whelp`) are always printed last due to necessarily coming later in the compiler pipeline.
Adds `help` flags to `-C` and `-Z` to avoid an error in `build_session_options`.
cc @bjorn3 [#t-compiler/major changes > Allow combining `--help -C help -Z help -… compiler-team#954 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Allow.20combining.20.60--help.20-C.20help.20-Z.20help.20-.E2.80.A6.20compiler-team.23954/near/564358190) - this currently maintains the behaviour of unrecognized options always failing-fast, as this happens within `getopt`s parsing, before we can even check if help options are present.
Supress some lookup errors if a module contains `compile_error!`
The problem is that when a macro expand to `compile_error!` because its input is malformed, the actual error message from the `compile_error!` might be hidden in a long list of other messages about using items that should have otherwise been generated by the macro.
So suppress error about missing items in that module.
Fixesrust-lang/rust#68838
The problem is that when a macro expand to `compile_error!` because
its input is malformed, the actual error message from the
`compile_error!` might be hidden in a long list of other messages about
using items that should have otherwise been generated by the macro.
So suppress error about missing items in that module.
Fixes issue 68838
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#148769 (Stabilize `alloc_layout_extra`)
- rust-lang/rust#150200 (Add title field to `ice.md` issue template)
- rust-lang/rust#150955 (Underscore-prefixed bindings are explicitly allowed to be unused)
- rust-lang/rust#151200 (time: Add saturating arithmetic for `SystemTime`)
- rust-lang/rust#151235 (Change field `bit_width: usize` to `bits: u32` in type info)
- rust-lang/rust#151242 (Port #[needs_allocator] to attribute parser)
- rust-lang/rust#151274 (Include a link to `count_ones` in the docs for `uN::count_zeros` [docs only])
- rust-lang/rust#151279 (remove trailing periods in built-in attribute gate messages)
r? @ghost
Port #[needs_allocator] to attribute parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
Ports needs_allocator attribute to the new attribute parser.
Note: this is a deprecated and feature gated attribute.
time: Add saturating arithmetic for `SystemTime`
This commit implements the following methods:
* `SystemTime::saturating_add`
* `SystemTime::saturating_sub`
* `SystemTime::saturating_duration_since`
The implementation of these methods is rather trivial, as the main logic lies behind the constants `SystemTime::MIN` and `SystemTime::MAX`.
See also:
* Accepted ACP: rust-lang/libs-team#718
* Tracking Issue: rust-lang/rust#151199
Thanks to 107634 and some improvements in LLVM (particularly `dead_on_unwind`), the method actually optimizes reasonably well now.
So focus the discussion on the fundamental ordering differences where the optimizer might never be able to fix it because of the different behaviour, and encouraging `Iterator::map` where an array wasn't actually ever needed.
When `[u8]::is_ascii()` is compiled with `-C target-cpu=native` on
AVX-512 CPUs, LLVM generates inefficient code. Because `is_ascii` is
marked `#[inline]`, it gets inlined and recompiled with the user's
target settings. The previous implementation used a counting loop that
LLVM auto-vectorizes to `pmovmskb` on SSE2, but with AVX-512 enabled,
LLVM uses k-registers and extracts bits individually with ~31
`kshiftrd` instructions.
This fix replaces the counting loop with explicit SSE2 intrinsics
(`_mm_loadu_si128`, `_mm_or_si128`, `_mm_movemask_epi8`) for x86_64.
`_mm_movemask_epi8` compiles to `pmovmskb`, forcing efficient codegen
regardless of CPU features.
Benchmark results on AMD Ryzen 5 7500F (Zen 4 with AVX-512):
- Default build: ~73 GB/s → ~74 GB/s (no regression)
- With -C target-cpu=native: ~3 GB/s → ~67 GB/s (22x improvement)
The loongarch64 implementation retains the original counting loop
since it doesn't have this issue.
Regression from: https://github.com/rust-lang/rust/pull/130733
When linting code generated by proc macros (like `derivative`), the
`elidable_lifetime_names` lint can produce fix suggestions with
overlapping spans. This causes `cargo clippy --fix` to fail with "cannot
replace slice of data that was already replaced".
This change adds `is_from_proc_macro` checks to the three lint entry
points (`check_item`, `check_impl_item`, `check_trait_item`) to skip
linting proc-macro generated code entirely.
Fixesrust-lang/rust-clippy#16316
---
changelog: [`elidable_lifetime_names`]: skip linting proc-macro
generated code to avoid broken fix suggestions
Not parsing changes, but a cleanup to make future changes easier. This
makes uplifting a lint it's own command rather than being part of
`rename_lint`. Uplifting and deprecation now also share code for
filesystem changes.
The `deprecate` command has a slight regression in that no longer
removes the lint from the lint pass declaration. This will be fixed in a
later PR where those are parsed and formatted.
changelog: none
This change expands the `double_comparisons` lint to check for
expressions of the form `x != y && x >= y` and `x != y && x <= y`. Since
the lint already checks for their dual (`x == y || x < y` and `x == y ||
x > y`, respectively) while also checking for `x <= y && x >= y` and its
dual `x > y || x < y`, it seemed like these two new cases were, in some
sense, missing.
Issues rust-lang/rust-clippy#685 and rust-lang/rust-clippy#753 appear
pertinent here.
----
changelog: [`double_comparisons`]: check and offer suggestions for
expressions such as `x != y && x >= y`
`oprnd_t` was used both for the type of the operand of a unary operator
and for the type of the operator expression as a whole. Now it's only
used for the operand's type.
Only `==` (and thus `!=`) are supposed to be commutative according to
Rust's documentation. Do not make assumptions about other operators
whose meaning may depend on the types on which they apply. However,
special-case operators known to be commutative for primitive types
such as addition or multiplication.
changelog: [`needless_continue`]: `allow` and `expect` attributes can
also be used on the statement triggering the lint instead of only the
whole loop.
Fixesrust-lang/rust-clippy#16256
I was evaluating this lint recently, and accepted using it because these
methods exist.
But the docs on the lint don't mention it, so I thought it would be
prudent to include it in the docs.
See also https://github.com/rust-lang/rust-clippy/pull/15384
changelog: [`cast_possible_wrap`]: mention `cast_{un,}signed()` methods
in the documentation
changelog: [`cast_possible_wrap`]: mention `cast_{un,}signed()` methods in doc
I was evaluating this lint recently, and accepted using it
because these methods exist.
But the docs on the lint don't mention it, so I thought
it would be prudent to include it in the docs.
See also https://github.com/rust-lang/rust-clippy/pull/15384
Co-authored-by: Kaur Kuut <strom@nevermore.ee>
Co-authored-by: Samuel Tardieu <sam@rfc1149.net>
This commit implements the following methods:
* `SystemTime::saturating_add`
* `SystemTime::saturating_sub`
* `SystemTime::saturating_duration_since`
The implementation of these methods is rather trivial, as the main logic
lies behind the constants `SystemTime::MIN` and `SystemTime::MAX`.
Move the is_from_proc_macro check inside check_fn_inner to be called
only right before emitting lints, rather than at the entry points.
This avoids the expensive check when early returns would prevent any
lint emission anyway.
Add tests for proc-macro generated code covering all check locations:
- Standalone functions
- Methods in impl blocks
- Trait methods
- Impl blocks with extra lifetimes
If we encounter `fn foo<T: Trait()`, the recovery logic would it as if `Trait` was intended to use the Fn-like trait syntax, but if we don't know for certain that we've parsed a full trait bound (`fn foo<T: Trait()>`), we bail from the recovery as more likely there could have been a missing closing `>` and the `(` corresponds to the start of the fn parameter list.
Also enables the feature for compiler_builtins as otherwise
this causes a warning and conflicts with the Float extension trait
Explicitly use Float trait BITS in miri tests to
prevent warnings against upcoming BITS field for floats
I came upon this code pattern recently and thought it'd make a good
lint. The colleague who first wrote it was at least pretty surprised
that there is a standard library function for it.
---
changelog: add [`manual_take`] lint
After a recent introduction of per-package flycheck for JSON projects, the code
assumed that `world.flycheck` indices matched `world.workspaces` indices.
However, not all workspaces have flycheck enabled (e.g., JSON projects
without a flycheck template configured), so the flycheck vector can be
shorter than the workspaces vector.
This caused an index-out-of-bounds panic when saving a file in a JSON
project without flycheck configured:
thread 'Worker' panicked at notification.rs:
index out of bounds: the len is 0 but the index is 0
Fix by looking up the flycheck handle by its ID (which is the workspace
index set during spawn) rather than using the workspace index directly
as a vector index.
When linting code generated by proc macros (like `derivative`), the
`elidable_lifetime_names` lint can produce fix suggestions with
overlapping spans. This causes `cargo clippy --fix` to fail with
"cannot replace slice of data that was already replaced".
This change adds `is_from_proc_macro` checks to the three lint entry
points (`check_item`, `check_impl_item`, `check_trait_item`) to skip
linting proc-macro generated code entirely.
Fixes#16316
It's described as a "backwards compatibility hack to keep the diff
small". Removing it requires only a modest amount of churn, and the
resulting code is clearer without the invisible derefs.
See also #135634, #149159, and rust-lang/hashbrown#662.
This includes an in-tree upgrade of `indexmap` as well, which uses the
new `HashTable` buckets API internally, hopefully impacting performance
for the better!
Enum variant layouts don't need to store a full `LayoutShape`; just storing
the fields offsets is enough and all other information can be inferred from
the parent layout:
- size, align and ABI don't make much sense for individual variants and
should generally be taken from the parent layout instead;
- variants always have `fields: FieldsShape::Arbitrary { .. }` and
`variant: VariantShape::Single { .. }`.
For simplicity's sake, this also changes the lint to always suggest
`to_bytes`, as it is somewhat hard to find out whether a type could
dereference to `CString` (which is what `as_bytes` would require)
This tries to clarify a few things regarding fmt syntax:
- The comment on `Parser::word` seems to be wrong, as that
underscore-prefixed words are just fine. This was changed in
https://github.com/rust-lang/rust/pull/66847.
- I struggled to follow the description of the width argument. It
referred to a "second argument", but I don't know what second argument
it is referring to (which is the first?). Either way, I rewrote the
paragraph to try to be a little more explicit, and to use shorter
sentences.
- The description of the precision argument wasn't really clear about
the distinction of an Nth argument and a named argument. I added
a sentence to try to emphasize the difference.
- `IDENTIFIER_OR_KEYWORD` was changed recently in
https://github.com/rust-lang/reference/pull/2049 to include bare `_`.
But fmt named arguments are not allowed to be a bare `_`.
The inline(always) attribute is now applied to the call site when a
function has target features enabled so that it can determine that the
call is safe to inline.
Add a note for tests-related lints that clippy needs to be run with
`--tests` argument to actually check tests.
changelog: [`ignore_without_reason`, `redundant_test_prefix`]: Mention
an extra `clippy` argument needed to check tests
Fixesrust-lang/rust-clippy#16111
Add a note to tests-related lint descriptions that clippy needs to be
run with e.g. `--tests` argument to actually check tests, which is not
quite obvious.
mGCA: Support array expression as direct const arguments
tracking issue: rust-lang/rust#132980resolve: rust-lang/rust#150612
Support array expression as direct const arguments (e. g. [1, 2, N]) in min_generic_const_args.
todo:
* [x] Rebase another mGCA PR
* [x] Add more test case
* [x] Modify clippy code
The previous tests ignored statements in a block and only looked at the
final expression to determine if the block was made of a single `break`.
changelog: [`while_let_loop`]: do not ignore statements before a `break`
when simplifying loop
Fixesrust-lang/rust-clippy#16378
They suffer from an unacceptable amount of false positives after #21209.
Another option to disable them is to include them in `rust-analyzer.diagnostics.disable` by default, but that will mean users could override that.
In https://github.com/rust-lang/rust/pull/119999, the length field of
the header was changed from 4 bytes to 8. One of the headers in
`batch_copy` was missed though, so it sends the wrong size. Fix by
switching to `create_header` in that spot too.
Closesrust-lang/rust-clippy#14946
Implemented as an enhancement to `needless_collect`
changelog: [`needless_collect`] enhance to cover vec `push`-alike cases
fixes false positives for `undocumented_unsafe_blocks`
https://github.com/rust-lang/rust-clippy/issues/16210
Same-line comments in macros `(e.g., let _x =// SAFETY: ...)` and inner
safety comments `(e.g., unsafe { // SAFETY: ... })` were not recognized
because
48821414b7/clippy_lints/src/undocumented_unsafe_blocks.rs (L794)
only checked for lines starting with // or /*.
note: `block_has_inner_safety_comment` does not respect
`accept-comment-above-statement` or `accept-comment-above-attributes`.
These configs control comments above statements or attributes; inner
comments are inside the block, so no ambiguity exists.
```
changelog: [`undocumented_unsafe_block`]: recognize safety comments inside blocks and on same line in macros
```
r? @llogiq
This option was used to gate `f16` and `f128` when support across
backends and targets was inconsistent. We now have the rustc builtin cfg
`target_has_reliable{f16,f128}` which has taken over this usecase.
Remove no-f16-f128 since it is now unused and redundant.
Pointing to the missing method definition in external crates will use
paths which depend on the system, and even on the Rust compiler version
used when the iterator is defined in the standard library.
When the trait being implemented and whose method is missing is
external, point only to the trait implementation. The user will be able
to figure out, or even navigate using their IDE, to the proper
definition.
As a side-effect, this will remove a large lintcheck churn at every
Rustup for this lint.
changelog: [`missing_trait_methods`]: better help message
Pointing to the missing method definition in external crates will use
paths which depend on the system, and even on the Rust compiler version
used when the iterator is defined in the standard library.
When the trait being implemented and whose method is missing is
external, point only to the trait implementation. The user will be able
to figure out, or even navigate using their IDE, to the proper
definition.
As a side-effect, this will remove a large lintcheck churn at every Rustup
for this lint.
Reflection MVP
I am opening this PR for discussion about the general design we should start out with, as there are various options (that are not too hard to transition between each other, so we should totally just pick one and go with it and reiterate later)
r? @scottmcm and @joshtriplett
project goal issue: https://github.com/rust-lang/rust-project-goals/issues/406
tracking issue: https://github.com/rust-lang/rust/issues/146922
The design currently implemented by this PR is
* `TypeId::info` (method, usually used as `id.info()` returns a `Type` struct
* the `Type` struct has fields that contain information about the type
* the most notable field is `kind`, which is a non-exhaustive enum over all possible type kinds and their specific information. So it has a `Tuple(Tuple)` variant, where the only field is a `Tuple` struct type that contains more information (The list of type ids that make up the tuple).
* To get nested type information (like the type of fields) you need to call `TypeId::info` again.
* There is only one language intrinsic to go from `TypeId` to `Type`, and it does all the work
An alternative design could be
* Lots of small methods (each backed by an intrinsic) on `TypeId` that return all the individual information pieces (size, align, number of fields, number of variants, ...)
* This is how C++ does it (see https://lemire.me/blog/2025/06/22/c26-will-include-compile-time-reflection-why-should-you-care/ and https://isocpp.org/files/papers/P2996R13.html#member-queries)
* Advantage: you only get the information you ask for, so it's probably cheaper if you get just one piece of information for lots of types (e.g. reimplementing size_of in terms of `TypeId::info` is likely expensive and wasteful)
* Disadvantage: lots of method calling (and `Option` return types, or "general" methods like `num_fields` returning 0 for primitives) instead of matching and field accesses
* a crates.io crate could implement `TypeId::info` in terms of this design
The backing implementation is modular enough that switching from one to the other is probably not an issue, and the alternative design could be easier for the CTFE engine's implementation, just not as nice to use for end users (without crates wrapping the logic)
One wart of this design that I'm fixing in separate branches is that `TypeId::info` will panic if used at runtime, while it should be uncallable
- only mention the type once
- put types in backticks
- only highlight the method name in the suggestion
- removes the need for a snippet
- makes for finer diffs (seen through `cargo dev lint`)
`GetHostNameW` is not available under Windows 7, leading to dynamic
linking failures upon program executions. For now, as it is still
unstable, this therefore appropriately cfg-gates the feature in order to
mark the Win7 as unsupported with regards to this particular feature.
Porting the functionality for Windows 7 would require changing the
underlying system call and so more work for the immediate need.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
While working on rust-lang/rust-clippy#16368, I found that this function
doesn't work correctly, presumably because the author was befuddled with
the negation.
r? @samueltardieu
---
changelog: none
in `LimitStack::pop_atr` always call `stack.pop()`.
It used to only be called inside a `debug_assert!` so the stack was not
popped in release builds.
Running `TESTNAME=cognitive_complexity cargo uitest --release` used to
print
```
error: there was 1 unmatched diagnostic
--> tests/ui/cognitive_complexity.rs:121:4
|
121 | fn bloo() {
| ^^^^ Error[clippy::cognitive_complexity]: the function has a cognitive complexity
of (2/1)
|
```
The first commit adds to the ui test, which also fails in release, the
2nd commit fixes the tests.
changelog: [`cognitive_complexity`]: fix attribute stack not popping in
release builds
`Duration::from_mins` and `Duration::from_hours` where [recently
stabilized](https://github.com/rust-lang/rust/issues/140881) in Rust
1.91.0.
In our codebase we often times have things like
```rust
Duration::from_secs(5 * 60);
// Since Rust 1.91.0 one can use
Duration::from_mins(5)
```
During the Rust 1.91.0 bump I noticed we can finally switch to
`Duration::from_mins(5)`, but many users might not be aware of this. I
started manually updating the places, but halfway through I figured
"Can't a lint do this for me?", so I added exactly that in this PR. It
does it for all stabilized `from_XXX` time units.
changelog: Add new [`duration_suboptimal_units`] lint
Closesrust-lang/rust-clippy#16335
The `LimitStack::pop_attrs` function used to pop from the stack in
`debug_assert_eq!` and check the value. The `pop` operation was therefore
only executed in debug builds, leading to an unbalanced stack in
release builds when attributes were present.
This change ensures the `pop` operation is always executed, by moving
it out of the debug-only assertion. The assertion is kept for debug
builds.
changelog: fix unbalanced stack in attributes
changelog: [`unnecessary_sort_by`]: respect applicability reduction due
to `Sugg`
changelog: [`unnecessary_sort_by`]: don't lint if `std` or `core` are
required for a suggestion but unavailable
The previous fix only handled `String`+`str`.
changelog: [`arithmetic_side_effects`]: do not warn on `String` +
`String`
Fixesrust-lang/rust-clippy#14054 (for good hopefully)
rust-analyzer has handy prebuilt `cargo doc` output at
https://rust-lang.github.io/rust-analyzer/ide/
However, it doesn't include private definitions, which makes it less
useful when trying to learn unfamiliar parts of the codebase.
Instead, pass `--document-private-items` so the HTML includes
information on private types and modules too. rustdoc renders these
with a padlock icon, so it's still clear that they're private.
This change also exposes some more rustdoc warnings, which I've fixed.
fix `Expr::can_have_side_effects` for `[x; N]` style array literal and binary expressions
AFAIK `[0; 3]` is basically a syntax sugar for `[0, 0, 0]` so it should return whether the repeat's element can have side effects, like what it does on arrays.
And it seems that the rule for unary operators and indexings can be applied to binary operators as well.
Update `literal-escaper` version to `0.0.7`
It removes the `std` dependency for this crate (which doesn't change anything for rustc 😄 ).
cc @bjorn3
r? @Urgau
- Do not store the `MacroCallId` of the "real" expansion anywhere, so that the IDE layer could not expand it by mistake
- Fix a stupid bug where we used the directive of the `derive` itself instead of of the macro, leading us to re-expand it again and again.
Because (1) it is what we use when there is no relevant config
(2) we automatically use either rust-project.json's flycheck, or cargo
This also puts check_command config into CargoOptions. It's a cargo option, after all.
This requires us to add $saved_file / {saved_file} interpolation back to restart_for_package.
Otherwise we break existing users of $saved_file. No grand reason why we can't delete saved_file
later, although I would just leave it because sometimes a build system might really know better
which target(s) to build, including multiple targets.
You should be able to flycheck a ProjectJson crate based on its build label.
This paves the way for that.
Context: I don't think this has been working for some time. It used to be that
we would use cargo to build ProjectJson crates. Support for ProjectJson seems
to have been somewhat steamrolled in PR 18845 (e4bf6e1bc36e4cbc8a36d7911788176eb9fac76e).
This flag allows specifying the threshold size for placing static data
in large data sections when using the medium code model on x86-64.
When using -Ccode-model=medium, data smaller than this threshold uses
RIP-relative addressing (32-bit offsets), while larger data uses
absolute 64-bit addressing. This allows the compiler to generate more
efficient code for smaller data while still supporting data larger than
2GB.
This mirrors the -mlarge-data-threshold flag available in GCC and Clang.
The default threshold is 65536 bytes (64KB) if not specified, matching
LLVM's default behavior.
Example
---
```rust
fn main() {
let cond = true;
match 92 {
3 => true,
x if cond => if x $0> 10 {
false
} else if x > 5 {
true
} else if x > 4 || x < -2 {
false
} else {
true
},
}
}
```
**Before this PR**
```rust
fn main() {
let cond = true;
match 92 {
3 => true,
x if x > 10 => false,
x if x > 5 => true,
x if x > 4 || x < -2 => false,
x => true,
}
}
```
**After this PR**
```rust
fn main() {
let cond = true;
match 92 {
3 => true,
x if cond && x > 10 => false,
x if cond && x > 5 => true,
x if cond && (x > 4 || x < -2) => false,
x if cond => true,
}
}
```
Add proper line/column resolution for proc-macro spans via a callback
mechanism. Previously these methods returned hardcoded 1 values.
The implementation adds:
- SubRequest::LineColumn and SubResponse::LineColumnResult to the
bidirectional protocol
- ProcMacroClientInterface::line_column() method
- Callback handling in load-cargo using LineIndex
- Server implementation in RaSpanServer that uses the callback
- a test for Span::line() and Span::column() in proc-macro server
Add fn_like_span_line_column test proc-macro that exercises the new
line/column API, and a corresponding test with a mock callback.
git can be configured to use more than 7 characters for conflict markers, and jj automatically uses longer conflict markers when the text contains any char sequence that could be confused with conflict markers. Ensure that we only point at markers that are consistent with the start marker's length.
Ensure that we only consider char sequences at the beginning of a line as a diff marker.
In the process also document that new `--remap-path-scope` scopes may be
added in the future, and that the `all` scope always represent all the
scopes.
Co-authored-by: David Wood <agile.lion3441@fuligin.ink>
warning: `#[must_use]` attribute cannot be used on trait methods in impl blocks
--> crates/core_simd/src/masks/bitmask.rs:173:5
|
173 | #[must_use = "method returns a new mask and does not mutate the original value"]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= help: `#[must_use]` can be applied to data types, foreign functions, functions, inherent methods, provided trait methods, required trait methods, traits, and unions
= note: `#[warn(unused_attributes)]` (part of `#[warn(unused)]`) on by default
warning: `#[must_use]` attribute cannot be used on trait methods in impl blocks
--> crates/core_simd/src/masks/bitmask.rs:190:5
|
190 | #[must_use = "method returns a new mask and does not mutate the original value"]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= help: `#[must_use]` can be applied to data types, foreign functions, functions, inherent methods, provided trait methods, required trait methods, traits, and unions
warning: `#[must_use]` attribute cannot be used on trait methods in impl blocks
--> crates/core_simd/src/masks/bitmask.rs:206:5
|
206 | #[must_use = "method returns a new mask and does not mutate the original value"]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= help: `#[must_use]` can be applied to data types, foreign functions, functions, inherent methods, provided trait methods, required trait methods, traits, and unions
warning: `#[must_use]` attribute cannot be used on trait methods in impl blocks
--> crates/core_simd/src/masks/bitmask.rs:222:5
|
222 | #[must_use = "method returns a new mask and does not mutate the original value"]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= help: `#[must_use]` can be applied to data types, foreign functions, functions, inherent methods, provided trait methods, required trait methods, traits, and unions
Add comments for the optimized function invariants to the caller
Add const-hack fixme for using while-loops
Document the invariant for the `_chunks` function
Add a debug assert for the tail handling invariant
Refactor the eq check into an inner function for reuse in tail checking
Rather than fall back to the simple implementation for tail handling,
load the last 16 bytes to take advantage of vectorization. This doesn't
seem to negatively impact check time even when the remainder count is low.
Refactor the current functionality into a helper function
Use `as_chunks` to encourage auto-vectorization in the optimized chunk processing function
Add a codegen test
Add benches for `eq_ignore_ascii_case`
The optimized function is initially only enabled for x86_64 which has `sse2` as
part of its baseline, but none of the code is platform specific. Other
platforms with SIMD instructions may also benefit from this implementation.
Performance improvements only manifest for slices of 16 bytes or longer, so the
optimized path is gated behind a length check for greater than or equal to 16.
- [Don't try to recover keyword as non-keyword identifier](https://github.com/rust-lang/rust/pull/150590), fixing an ICE that especially [affected rustfmt](https://github.com/rust-lang/rustfmt/issues/6739).
- [Fix `clippy::panicking_unwrap` false-positive on field access with implicit deref](https://github.com/rust-lang/rust-clippy/pull/16196).
- [Revert "Update wasm-related dependencies in CI"](https://github.com/rust-lang/rust/pull/152259), fixing file descriptor leaks on the `wasm32-wasip2` target.
Version 1.93.0 (2026-01-22)
==========================
<aid="1.93.0-Language"></a>
Language
--------
- [Stabilize several s390x `vector`-related target features and the `is_s390x_feature_detected!` macro](https://github.com/rust-lang/rust/pull/145656)
- [Stabilize declaration of C-style variadic functions for the `system` ABI](https://github.com/rust-lang/rust/pull/145954)
- [Emit error when using some keyword as a `cfg` predicate](https://github.com/rust-lang/rust/pull/146978)
- [During const-evaluation, support copying pointers byte-by-byte](https://github.com/rust-lang/rust/pull/148259)
- [LUB coercions now correctly handle function item types, and functions with differing safeties](https://github.com/rust-lang/rust/pull/148602)
- [Allow `const` items that contain mutable references to `static` (which is *very* unsafe, but not *always* UB)](https://github.com/rust-lang/rust/pull/148746)
- [Add warn-by-default `const_item_interior_mutations` lint to warn against calls which mutate interior mutable `const` items](https://github.com/rust-lang/rust/pull/148407)
- [Stop internally using `specialization` on the `Copy` trait as it is unsound in the presence of lifetime dependent `Copy` implementations. This may result in some performance regressions as some standard library APIs may now call `Clone::clone` instead of performing bitwise copies](https://github.com/rust-lang/rust/pull/135634)
- [Allow the global allocator to use thread-local storage and `std::thread::current()`](https://github.com/rust-lang/rust/pull/144465)
- [Make `BTree::append` not update existing keys when appending an entry which already exists](https://github.com/rust-lang/rust/pull/145628)
- [Don't require `T: RefUnwindSafe` for `vec::IntoIter<T>: UnwindSafe`](https://github.com/rust-lang/rust/pull/145665)
- [Include attribute and derive macros in search filters for "macros"](https://github.com/rust-lang/rust/pull/148176)
- [Include extern crates in search filters for `import`](https://github.com/rust-lang/rust/pull/148301)
- [Validate usage of crate-level doc attributes](https://github.com/rust-lang/rust/pull/149197). This means if any of `html_favicon_url`, `html_logo_url`, `html_playground_url`, `issue_tracker_base_url`, or `html_no_source` either has a missing value, an unexpected value, or a value of the wrong type, rustdoc will emit the deny-by-default lint `rustdoc::invalid_doc_attributes`.
<aid="1.93.0-Compatibility-Notes"></a>
Compatibility Notes
-------------------
- [Introduce `pin_v2` into the builtin attributes namespace](https://github.com/rust-lang/rust/pull/139751)
- [Update bundled musl to 1.2.5](https://github.com/rust-lang/rust/pull/142682)
- [On Emscripten, the unwinding ABI used when compiling with `panic=unwind` was changed from the JS exception handling ABI to the wasm exception handling ABI.](https://github.com/rust-lang/rust/pull/147224) If linking C/C++ object files with Rust objects, `-fwasm-exceptions` must be passed to the linker now. On nightly Rust, it is possible to get the old behavior with `-Zwasm-emscripten-eh=false -Zbuild-std`, but it will be removed in a future release.
- The `#[test]` attribute, used to define tests, was previously ignored in various places where it had no meaning (e.g on trait methods or types). Putting the `#[test]` attribute in these places is no longer ignored, and will now result in an error; this may also result in errors when generating rustdoc. [Error when `test` attribute is applied to structs](https://github.com/rust-lang/rust/pull/147841)
- Cargo now sets the `CARGO_CFG_DEBUG_ASSERTIONS` environment variable in more situations. This will cause crates depending on `static-init` versions 1.0.1 to 1.0.3 to fail compilation with "failed to resolve: use of unresolved module or unlinked crate `parking_lot`". See [the linked issue](https://github.com/rust-lang/rust/issues/150646#issuecomment-3718964342) for details.
- [User written types in the `offset_of!` macro are now checked to be well formed.](https://github.com/rust-lang/rust/issues/150465/)
- `cargo publish` no longer emits `.crate` files as a final artifact for user access when the `build.build-dir` config is unset
- [Upgrade the `deref_nullptr` lint from warn-by-default to deny-by-default](https://github.com/rust-lang/rust/pull/148122)
- [Add future-incompatibility warning for `...` function parameters without a pattern outside of `extern` blocks](https://github.com/rust-lang/rust/pull/143619)
- [Introduce future-compatibility warning for `repr(C)` enums whose discriminant values do not fit into a `c_int` or `c_uint`](https://github.com/rust-lang/rust/pull/147017)
- [Introduce future-compatibility warning against ignoring `repr(C)` types as part of `repr(transparent)`](https://github.com/rust-lang/rust/pull/147185)
Version 1.92.0 (2025-12-11)
==========================
@ -1435,7 +1555,7 @@ Compatibility Notes
- [Check well-formedness of the source type's signature in fn pointer casts.](https://github.com/rust-lang/rust/pull/129021) This partly closes a soundness hole that comes when casting a function item to function pointer
- [Use equality instead of subtyping when resolving type dependent paths.](https://github.com/rust-lang/rust/pull/129073)
- Linking on macOS now correctly includes Rust's default deployment target. Due to a linker bug, you might have to pass `MACOSX_DEPLOYMENT_TARGET` or fix your `#[link]` attributes to point to the correct frameworks. See <https://github.com/rust-lang/rust/pull/129369>.
- [Rust will now correctly raise an error for `repr(Rust)` written on non-`struct`/`enum`/`union` items, since it previous did not have any effect.](https://github.com/rust-lang/rust/pull/129422)
- [Rust will now correctly raise an error for `repr(Rust)` written on non-`struct`/`enum`/`union` items, since it previously did not have any effect.](https://github.com/rust-lang/rust/pull/129422)
- The future incompatibility lint `deprecated_cfg_attr_crate_type_name` [has been made into a hard error](https://github.com/rust-lang/rust/pull/129670). It was used to deny usage of `#![crate_type]` and `#![crate_name]` attributes in `#![cfg_attr]`, which required a hack in the compiler to be able to change the used crate type and crate name after cfg expansion.
Users can use `--crate-type` instead of `#![cfg_attr(..., crate_type = "...")]` and `--crate-name` instead of `#![cfg_attr(..., crate_name = "...")]` when running `rustc`/`cargo rustc` on the command line.
Use of those two attributes outside of `#![cfg_attr]` continue to be fully supported.
@ -1611,7 +1731,7 @@ Cargo
Compatibility Notes
-------------------
- We now [disallow setting some built-in cfgs via the command-line](https://github.com/rust-lang/rust/pull/126158) with the newly added [`explicit_builtin_cfgs_in_flags`](https://doc.rust-lang.org/rustc/lints/listing/deny-by-default.html#explicit-builtin-cfgs-in-flags) lint in order to prevent incoherent state, eg. `windows` cfg active but target is Linux based. The appropriate [`rustc` flag](https://doc.rust-lang.org/rustc/command-line-arguments.html) should be used instead.
- The standard library has a new implementation of `binary_search` which is significantly improves performance ([#128254](https://github.com/rust-lang/rust/pull/128254)). However when a sorted slice has multiple values which compare equal, the new implementation may select a different value among the equal ones than the old implementation.
- The standard library has a new implementation of `binary_search` which significantly improves performance ([#128254](https://github.com/rust-lang/rust/pull/128254)). However when a sorted slice has multiple values which compare equal, the new implementation may select a different value among the equal ones than the old implementation.
- [illumos/Solaris now sets `MSG_NOSIGNAL` when writing to sockets](https://github.com/rust-lang/rust/pull/128259). This avoids killing the process with SIGPIPE when writing to a closed socket, which matches the existing behavior on other UNIX targets.
- [Removes a problematic hack that always passed the --whole-archive linker flag for tests, which may cause linker errors for code accidentally relying on it.](https://github.com/rust-lang/rust/pull/128400)
- The WebAssembly target features `multivalue` and `reference-types` are now
@ -1761,7 +1881,7 @@ These changes do not affect any public interfaces of Rust, but they represent
significant improvements to the performance or internals of rustc and related
tools.
- [Add a Rust-forLinux `auto` CI job to check kernel builds.](https://github.com/rust-lang/rust/pull/125209/)
- [Add a Rust-for-Linux `auto` CI job to check kernel builds.](https://github.com/rust-lang/rust/pull/125209/)
Version 1.80.1 (2024-08-08)
===========================
@ -4399,7 +4519,7 @@ Compatibility Notes
saturating to `0` instead][89926]. In the real world the panic happened mostly
on platforms with buggy monotonic clock implementations rather than catching
programming errors like reversing the start and end times. Such programming
errors will now results in `0` rather than a panic.
errors will now result in `0` rather than a panic.
- In a future release we're planning to increase the baseline requirements for
the Linux kernel to version 3.2, and for glibc to version 2.17. We'd love
.note = for more information, visit <https://doc.rust-lang.org/reference/type-layout.html?highlight=repr#representations>
attr_parsing_unsafe_attr_outside_unsafe = unsafe attribute used without unsafe
.label = usage of unsafe attribute
attr_parsing_unsafe_attr_outside_unsafe_suggestion = wrap the attribute in `unsafe(...)`
attr_parsing_unstable_cfg_target_compact =
compact `cfg(target(..))` is experimental and subject to change
attr_parsing_unstable_feature_bound_incompatible_stability = item annotated with `#[unstable_feature_bound]` should not be stable
.help = If this item is meant to be stable, do not use any functions annotated with `#[unstable_feature_bound]`. Otherwise, mark this item as unstable with `#[unstable]`
attr_parsing_unsupported_instruction_set = target `{$current_target}` does not support `#[instruction_set({$instruction_set}::*)]`
attr_parsing_unsupported_literal_suggestion =
consider removing the prefix
attr_parsing_unused_multiple =
multiple `{$name}` attributes
.suggestion = remove this attribute
.note = attribute also specified here
attr_parsing_whole_archive_needs_static =
linking modifier `whole-archive` is only compatible with `static` linking kind
#[diag("item annotated with `#[unstable_feature_bound]` should not be stable")]
#[help(
"if this item is meant to be stable, do not use any functions annotated with `#[unstable_feature_bound]`. Otherwise, mark this item as unstable with `#[unstable]`"
