Fix ui pattern_types test for big-endian platforms
The newly added pattern types validity tests fail on s390x and presumably other big-endian systems, due to print of raw values with padding bytes.
To fix the tests remove the raw output values in the error note by `normalize-stderr`.
Stabilize `#![feature(precise_capturing_in_traits)]`
# Precise capturing (`+ use<>` bounds) in traits - Stabilization Report
Fixes https://github.com/rust-lang/rust/issues/130044.
## Stabilization summary
This report proposes the stabilization of `use<>` precise capturing bounds in return-position impl traits in traits (RPITITs). This completes a missing part of [RFC 3617 "Precise capturing"].
Precise capturing in traits was not ready for stabilization when the first subset was proposed for stabilization (namely, RPITs on free and inherent functions - https://github.com/rust-lang/rust/pull/127672) since this feature has a slightly different implementation, and it hadn't yet been implemented or tested at the time. It is now complete, and the type system implications of this stabilization are detailed below.
## Motivation
Currently, RPITITs capture all in-scope lifetimes, according to the decision made in the ["lifetime capture rules 2024" RFC](https://rust-lang.github.io/rfcs/3498-lifetime-capture-rules-2024.html#return-position-impl-trait-in-trait-rpitit). However, traits can be designed such that some lifetimes in arguments may not want to be captured. There is currently no way to express this.
## Major design decisions since the RFC
No major decisions were made. This is simply an extension to the RFC that was understood as a follow-up from the original stabilization.
## What is stabilized?
Users may write `+ use<'a, T>` bounds on their RPITITs. This conceptually modifies the desugaring of the RPITIT to omit the lifetimes that we would copy over from the method. For example,
```rust
trait Foo {
fn method<'a>(&'a self) -> impl Sized;
// ... desugars to something like:
type RPITIT_1<'a>: Sized;
fn method_desugared<'a>(&'a self) -> Self::RPITIT_1<'a>;
// ... whereas with precise capturing ...
fn precise<'a>(&'a self) -> impl Sized + use<Self>;
// ... desugars to something like:
type RPITIT_2: Sized;
fn precise_desugared<'a>(&'a self) -> Self::RPITIT_2;
}
```
And thus the GAT doesn't name `'a`. In the compiler internals, it's not implemented exactly like this, but not in a way that users should expect to be able to observe.
#### Limitations on what generics must be captured
Currently, we require that all generics from the trait (including the `Self`) type are captured. This is because the generics from the trait are required to be *invariant* in order to do associated type normalization.
And like regular precise capturing bounds, all type and const generics in scope must be captured.
Thus, only the in-scope method lifetimes may be relaxed with this syntax today.
## What isn't stabilized? (a.k.a. potential future work)
See section above. Relaxing the requirement to capture all type and const generics in scope may be relaxed when https://github.com/rust-lang/rust/issues/130043 is implemented, however it currently interacts with some underexplored corners of the type system (e.g. unconstrained type bivariance) so I don't expect it to come soon after.
## Implementation summary
This functionality is implemented analogously to the way that *opaque type* precise capturing works.
Namely, we currently use *variance* to model the capturedness of lifetimes. However, since RPITITs are anonymous GATs instead of opaque types, we instead modify the type relation of GATs to consider variances for RPITITs (along with opaque types which it has done since https://github.com/rust-lang/rust/pull/103491).
30f168ef81/compiler/rustc_middle/src/ty/util.rs (L954-L976)30f168ef81/compiler/rustc_type_ir/src/relate.rs (L240-L244)
Using variance to model capturedness is an implementation detail, and in the future it would be desirable if opaques and RPITITs simply did not include the uncaptured lifetimes in their generics. This can be changed in a forwards-compatible way, and almost certainly would not be observable by users (at least not negatively, since it may indeed fix some bugs along the way).
## Tests
* Test that the lifetime isn't actually captured: `tests/ui/impl-trait/precise-capturing/rpitit.rs` and `tests/ui/impl-trait/precise-capturing/rpitit-outlives.rs` and `tests/ui/impl-trait/precise-capturing/rpitit-outlives-2.rs`.
* Technical test for variance computation: `tests/ui/impl-trait/in-trait/variance.rs`.
* Test that you must capture all trait generics: `tests/ui/impl-trait/precise-capturing/forgot-to-capture-type.rs`.
* Test that you cannot capture more than what the trait specifies: `tests/ui/impl-trait/precise-capturing/rpitit-captures-more-method-lifetimes.rs` and `tests/ui/impl-trait/precise-capturing/rpitit-impl-captures-too-much.rs`.
* Undercapturing (refinement) lint: `tests/ui/impl-trait/in-trait/refine-captures.rs`.
### What other unstable features may be exposed by this feature?
I don't believe that this exposes any new unstable features indirectly.
## Remaining bugs and open issues
Not aware of any open issues or bugs.
## Tooling support
Rustfmt: ✅ Supports formatting `+ use<>` everywhere.
Clippy: ✅ No support needed, unless specific clippy lints are impl'd to care for precise capturing itself.
Rustdoc: ✅ Rendering `+ use<>` precise capturing bounds is supported.
Rust-analyzer: ✅ Parser support, and then lifetime support isn't needed https://github.com/rust-lang/rust/pull/138128#issuecomment-2705292494 (previous: ~~❓ There is parser support, but I am unsure of rust-analyzer's level of support for RPITITs in general.~~)
## History
Tracking issue: https://github.com/rust-lang/rust/issues/130044
* https://github.com/rust-lang/rust/pull/131033
* https://github.com/rust-lang/rust/pull/132795
* https://github.com/rust-lang/rust/pull/136554
add FCW to warn about wasm ABI transition
See https://github.com/rust-lang/rust/issues/122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following:
- scalar arguments are fine
- including 128 bit types, they get passed as two `i64` arguments in both ABIs
- `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes)
- all return values are fine
`@bjorn3` `@alexcrichton` `@Manishearth` is that correct?
I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this?
IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments.
Tracking issue: https://github.com/rust-lang/rust/issues/138762
Transition plan blog post: https://github.com/rust-lang/blog.rust-lang.org/pull/1531
try-job: dist-various-2
Rollup of 8 pull requests
Successful merges:
- #135745 (Recognise new IPv6 non-global range from IETF RFC 9602)
- #137247 (cg_llvm: Reduce the visibility of types, modules and using declarations in `rustc_codegen_llvm`.)
- #138317 (privacy: Visit types and traits in impls in type privacy lints)
- #138581 (Abort in deadlock handler if we fail to get a query map)
- #138776 (coverage: Separate span-extraction from unexpansion)
- #138886 (Fix autofix for `self` and `self as …` in `unused_imports` lint)
- #138924 (Reduce `kw::Empty` usage, part 3)
- #138929 (Visitors track whether an assoc item is in a trait impl or an inherent impl)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix autofix for `self` and `self as …` in `unused_imports` lint
This fixes two problems with the autofixes for the `unused_imports` lint:
- `use std::collections::{HashMap, self as coll};` would suggest, when `HashMap` is unused, the incorrect `use std::collections::self as coll;` which does not compile.
- `use std::borrow::{self, Cow};` would suggest, when `self` is unused, `use std::borrow::{Cow};`, which contains unnecessary brackets.
The first problem was reported in rust-lang/rust-clippy#14450, the second found while fixing the first one.
Fix#133750
(thanks to `@richardsamuels` for spotting the duplicate)
compiletest: Support matching on diagnostics without a span
Using `//~? ERROR my message` on any line of the test.
The new checks are exhaustive, like all other `//~` checks, and unlike the `error-pattern` directive that is sometimes used now to check for span-less diagnostics.
This will allow to eliminate most on `error-pattern` directives in compile-fail tests (except those that are intentionally imprecise due to platform-specific diagnostics).
I didn't migrate any of `error-pattern`s in this PR though, except those where the migration was necessary for the tests to pass.
Fix/tweak some tests in new solver
Bunch of miscellaneous new solver tweaks that I found from the failing tests. Can split these out, but they all seemed small enough to not warrant separate PRs.
r? lcnr
Reintroduce remote-test support in run-make tests
The old Makefile-based infrastructure included support for executing binaries with remote-test-client if configured, but that didn't get ported to run_make_support as part of the rmake migration.
This PR re-introduces back that support, with the same implementation (and limitations) of the original Makefile-based support.
[Old Makefile-based implementation of this](9b8accbeb6/tests/run-make/tools.mk (L65-L74))
try-job: armhf-gnu
Lower to a memset(undef) when Rvalue::Repeat repeats uninit
Fixes https://github.com/rust-lang/rust/issues/138625.
It is technically correct to just do nothing. But if we actually do nothing, we may miss that this is de-initializing something, so instead we just lower to a single memset that writes undef. This is still superior to the memcpy loop, in both quality of code we hand to the backend and LLVM's final output.
Lower BinOp::Cmp to llvm.{s,u}cmp.* intrinsics
Lowers `mir::BinOp::Cmp` (`three_way_compare` intrinsic) to the corresponding LLVM `llvm.{s,u}cmp.i8.*` intrinsics.
These are the intrinsics mentioned in https://github.com/rust-lang/rust/pull/118310, which are now available in LLVM 19.
I couldn't find any follow-up PRs/discussions about this, please let me know if I missed something.
r? `@scottmcm`
I saw someone post a code sample that contained these two attributes,
which immediately made me suspicious.
My suspicions were confirmed when I did a small test and checked the
compiler source code to confirm that in these cases, `#[inline]` is
indeed ignored (because you can't exactly `LocalCopy`an unmangled symbol
since that would lead to duplicate symbols, and doing a mix of an
unmangled `GloballyShared` and mangled `LocalCopy` instantiation is too
complicated for our current instatiation mode logic, which I don't want
to change right now).
So instead, emit the usual unused attribute lint with a message saying
that the attribute is ignored in this position.
I think this is not 100% true, since I expect LLVM `inlinehint` to still
be applied to such a function, but that's not why people use this
attribute, they use it for the `LocalCopy` instantiation mode, where it
doesn't work.
This fixes two problems with the autofixes for the `unused_imports`
lint:
- `use std::collections::{HashMap, self as coll};` would suggest, when
`HashMap` is unused, the incorrect `use std::collections::self as coll;`
which does not compile.
- `use std::borrow::{self, Cow};` would suggest, when `self` is unused,
`use std::borrow::{Cow};`, which contains unnecessary brackets.
The newly added pattern types validity tests fail on s390x and
presumably other big-endian systems, due to print of raw values
with padding bytes.
To fix the tests remove the raw output values in the error note by
`normalize-stderr`.
rustdoc: be more strict about "Methods from Deref"
fixes#137083fixes#24686
Currently done:
* [x] fix `render_assoc_items_inner
* [x] fix sidebar logic
* [x] port test from https://github.com/rust-lang/rust/pull/137564
* [x] add test for sidebar items
Note that this does not yet fix the sidebar logic.
Simplify `PartialOrd` on tuples containing primitives
We noticed in https://github.com/rust-lang/rust/pull/133984#issuecomment-2704011800 that currently the tuple comparison code, while it [does optimize down](https://github.com/rust-lang/rust/blob/master/tests/codegen/comparison-operators-2-tuple.rs) today, is kinda huge: <https://rust.godbolt.org/z/xqMoeYbhE>
This PR changes the tuple code to go through an overridable "chaining" version of the comparison functions, so that for simple things like `(i16, u16)` and `(f32, f32)` (as seen in the new MIR pre-codegen test) we just directly get the
```rust
if lhs.0 == rhs.0 { lhs.0 OP rhs.0 }
else { lhs.1 OP rhs.1 }
```
version in MIR, rather than emitting a mess for LLVM to have to clean up.
Test added in the first commit, so you can see the MIR diff in the second one.
Add unstable `--print=supported-crate-types` option
MCP: https://github.com/rust-lang/compiler-team/issues/836
Tracking issue: https://github.com/rust-lang/rust/issues/138640
### Test coverage
Two tests:
1. `tests/ui/print-request/stability.rs` to check that `--print=supported-crate-types` is `-Zunstable-options`-gated
2. `tests/ui/print-request/supported-crate-types.rs` is added as a basic smoke test. Observe that the compiler stdout corresponds to the below *Example output* section (e.g. `proc-macro` is unsupported on `wasm32-unknown-unknown` currently).
### Example output
<details>
<summary>For `x86_64-unknown-linux-gnu`</summary>
Notice the presence of `{c,}dylib` and `proc-macro`:
```
bin
cdylib
dylib
lib
proc-macro
rlib
staticlib
```
</details>
<details>
<summary>For `wasm32-unknown-unknown`</summary>
Notice the absence of `dylib` and `proc-macro`:
```
bin
cdylib
lib
rlib
staticlib
```
</details>
<details>
<summary>For `x86_64-unknown-linux-musl`</summary>
Notice the absence of `{c,}dylib` but presence of `proc-macro`:
```
bin
lib
proc-macro
rlib
staticlib
```
</details>
### Documentation
I added an entry in the unstable book's print request section to document this `supported-crate-types` print request.
### Unresolved questions
- [ ] (Name bikeshedding) is `supported-crate-types` a good name for the print request? I'm inclined to say it's good enough for an unstable print request, but may be worth revisiting at stabilization time.
### Stability
This print request being added is *unstable* in this PR. A separate stabilization PR following the usual compiler flag stabilization procedure should be filed for stabilization after some baking time.
### Review remarks
Best reviewed commit-by-commit.
r? compiler
Add MIR pre-codegen tests to track #138544
I don't know how best to fix the problem yet, but wanted to check in some tests to demonstrate it and make sure that they get updated to keep it fixed if anyone does fix it 🙂
No code changes; just the tests for #138544.
