Support syntax for one-line trait reuse
This PR adds support for reusing the whole trait with a one-line reuse syntax and is part of the delegation feature rust-lang/rust#118212:
```rust
trait T {
fn foo(&self);
}
struct S;
impl T for S { ... }
struct Wrapper(S);
reuse impl T for Wrapper { self.0 }
```
The core idea is that we already have support for glob reuse, so in this scenario we want to transform one-line reuse into a trait impl block with a glob reuse in the following way:
```rust
//Before
reuse impl T for Wrapper { self.0 }
//After
impl T for Wrapper {
reuse T::* { self.0 }
}
```
It seems like this task can be solved during parsing stage, when we encountered a one-line trait reuse, we can expand into this impl block right away, and the code which was already written to expand glob delegations will take care about the rest. We will copy trait path into glob reuse path.
The implementation of the transformation reuses already existing methods for `impl` parsing, however, we do not parse inner `impl` items, instead we parse "inner items" as delegation body. Thus, we do not have to deal with generics, consts, unsafe and other `impl` related features.
Other syntax possibility is trying to shorten one-line reuse by replacing `impl` keyword with `reuse` keyword:
```rust
reuse T for Wrapper { self.0 }
```
In this case implementation may become more complicated, and the syntax more confusing, as keywords such as `const` or `unsafe` will precede `reuse`, and there are also generics:
```rust
unsafe reuse<T1, T2> T for Wrapper { self.0 }
```
In the first (currently implemented) version reuse is placed in the beginning of the item, and it is clear that we will reuse trait implementation, while in the second, shorter version, the `reuse` keyword may be lost in generics and keywords that may precede `impl`.
r? ``@petrochenkov``
std: Use `usleep` temporarily on WASI targets
This fixes some fallout from rust-lang/rust#147572 where the `thread::sleep` function is is broken on `wasm32-wasip2` after that PR. The cause for this is a broken implementation of `nanosleep` in wasi-libc itself which is being fixed in WebAssembly/wasi-libc#696. Similar to rust-lang/rust#149864 this avoids the problematic function for now while the wasi-libc changes take some time to propagate into a wasi-sdk release.
Closesrust-lang/rust#150290
remove llvm_enzyme and enzyme fallbacks from most places
Using dlopen to get symbols has the nice benefit that rustc itself doesn't depend on libenzyme symbols anymore. We can therefore delete most fallback implementations in the backend (independently of whether we enable enzyme or not). When trying to use autodiff on nightly, we will now fail with a nice error if and only if we fail to load libEnzyme-21.so in our backend.
Verified:
Build as nightly, without Enzyme
Build as nightly, with Enzyme
Build as stable (without Enzyme)
With this PR we will now run `tests/ui/autodiff` on nightly, the tests are passing.
r? `@kobzol`
This fixes some fallout from 147572 where the `thread::sleep` function
is is broken on `wasm32-wasip2` after that PR. The cause for this is a
broken implementation of `nanosleep` in wasi-libc itself which is being
fixed in WebAssembly/wasi-libc/696. Similar to 149999 this avoids the
problematic function for now while the wasi-libc changes take some time
to propagate into a wasi-sdk release.
Don't lint on interior mutable `const` item coming from derefs
This PR fixes the `const_item_interior_mutations` lint so we don't lint on interior mutable `const` item coming from derefs.
Fixes https://github.com/rust-lang/rust/issues/150157
Detail expectation on non-`()` block tail in `if` then condition with no `else`
When encountering an `if` expression with no `else` where the then block has a tail expression, we emit an E0308 type error. We now explain why `()` was expected.
Partially address rust-lang/rust#144911.
fix ICE when {{root}} appears in import suggestions
Fixesrust-lang/rust#150103
When wrong nested imports like `use A::{::Fish}` were used, the internal {{root}} would appear in diagnostic suggestions, causing an ICE in `join_path_idents` which asserted that **{{root}} should only appear at the start of a path**.
r? ``@matthiaskrgr``
When encountering an `if` expression with no `else` where the then
block has a tail expression, we emit an E0308 type error. We now explain
why `()` was expected.
interpreter/visitor: always iterate in in-memory order
Now that this is directly available in the type, there's no reason to ever iterate in any other order.
Port `#[cfi_encoding]` to attribute parser
The error message is kind of saying the same thing twice, would like input on which .expect function I should use instead to not have it be double, otherwise this passes all tests locally where this attribute is used
r? `@JonathanBrouwer`
crash test readme: point to rustc-dev-guide
There is information that is duplicated here and in rustc-dev-guide, and the latter is more comprehensive, so point there.
Replace Rvalue::NullaryOp by a variant in mir::Operand.
Based on https://github.com/rust-lang/rust/pull/148151
This PR fully removes the MIR `Rvalue::NullaryOp`. After rust-lang/rust#148151, it was only useful for runtime checks like `ub_checks`, `contract_checks` and `overflow_checks`.
These are "runtime" checks, boolean constants that may only be `true` in codegen. It depends on a rustc flag passed to codegen, so we need to represent those flags cross-crate.
This PR replaces those runtime checks by special variants in MIR `ConstValue`. This allows code that expects constants to manipulate those as such, even if we may not always be able to evaluate them to actual scalars.
Fix d32 usage in Arm target specs
Fixes https://github.com/rust-lang/rust/issues/149399 - after checking with an LLVM engineer Rust's feature implications do correctly map to LLVM's. The target specs originally had +vfp3,+d16, but were mistakenly fixed to +vfp3,-d32 which disables vfp3 again.
Some targets specify +vfp2,-d32, and since vfp2 shouldn't imply d32 the -d32 is unneeded.
The list of Arm features is quite old and since Arm is now a target maintainer of many of them we'll go in and update them. We should probably add vfp3d16 and similar as rust has no way to express these right now after d16 was removed.
The LLVM features expand like this:
```
vfp4 -> vfp3 + fp16 + vfp4d16 + vfp4sp
vfp4d16 -> vfp3d16 + fp16 + fp64 + vfp4d16sp
vfp4sp -> vfp3sp + fp16 + d32 + vfp4d16sp
vfp4d16sp -> vfp3d16sp + fp16
vfp3 -> vfp2 + vfp3d16 + vfp3sp
vfp3d16 -> vfp2 + fp64 + vfp3d16sp
vfp3sp -> vfp2 + d32 + vfp3d16sp
vfp3d16sp -> vfp2sp
vfp2 -> vfp2sp + fp64
vfp2sp -> fpregs
```
`-neon` might be unnecessary too in many of these cases, but some default CPUs that Rust specifies will turn Neon on so that needs a bit more care. I can't see any LLVM cpus that enable D32.
Old description:
> Fixes https://github.com/rust-lang/rust/issues/149399 - this implication was likely a mistake and isn't enforced by LLVM. This is is a breaking change and any users specifying `vfp2/3/4` via `-Ctarget-features` or the `target_feature` attribute will need to add `d32` in to get the same behaviour. The target features are unstable so this is ok for Rust, and this is necessary as otherwise there's no way to specify a `vfp2-d16` configuration, for example.
>
> I expect these targets would have been broken by https://github.com/rust-lang/rust/pull/149173 as `-d32` would have disabled any `+vfpX` feature before it. With the removal of the implication the `-d32` went back to being unnecessary, but I've removed it anyway.
>
> As ``@RalfJung`` pointed out, thumbv7a-nuttx-eabihf looks to have been relying on this implication so I've added `+d32` to it's target spec.
Drop the From derive macro from the v1 prelude
This was accidentally added to the prelude in 3f4dc1e02d.
Fixes: rust-lang/rust#150165
r? `````@jdonszelmann`````
mir_build: Use the same length type for `TestableCase::Slice` and `TestKind::Len`
If we convert the minimum length to `u64` up-front when creating `TestableCase::Slice`, we can avoid more conversions to `u64` later.
There should be no change to compiler behaviour.
