This commit fixes an issue not found during #84988 where rustdoc is used
to document cross-platform intrinsics but it was requiring that
functions which use `#[target_feature]` are `unsafe` erroneously, even
if they're WebAssembly specific. Rustdoc today, for example, already has
a special case where it enables annotations like
`#[target_feature(enable = "simd128")]` on platforms other than
WebAssembly. The purpose of this commit is to relax the "require all
`#[target_feature]` functions are `unsafe`" requirement for all targets
whenever rustdoc is running, enabling all targets to fully document
other targets, such as WebAssembly, where intrinsics functions aren't
always `unsafe`.
BPF target support
This adds `bpfel-unknown-none` and `bpfeb-unknown-none`, two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target, where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker.
I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.
Allow raw pointers in SIMD types
Closes#85915 by loosening the strictness in typechecking and adding a test to guarantee it passes.
This still might be too strict, as references currently do pass monomorphization, but my understanding is that they are not guaranteed to be "scalar" in the same way.
rustc: Allow safe #[target_feature] on wasm
This commit updates the compiler's handling of the `#[target_feature]`
attribute when applied to functions on WebAssembly-based targets. The
compiler in general requires that any functions with `#[target_feature]`
are marked as `unsafe` as well, but this commit relaxes the restriction
for WebAssembly targets where the attribute can be applied to safe
functions as well.
The reason this is done is that the motivation for this feature of the
compiler is not applicable for WebAssembly targets. In general the
`#[target_feature]` attribute is used to enhance target CPU features
enabled beyond the basic level for the rest of the compilation. If done
improperly this means that your program could execute an instruction
that the CPU you happen to be running on does not understand. This is
considered undefined behavior where it is unknown what will happen (e.g.
it's not a deterministic `SIGILL`).
For WebAssembly, however, the target is different. It is not possible
for a running WebAssembly program to execute an instruction that the
engine does not understand. If this were the case then the program would
not have validated in the first place and would not run at all. Even if
this were allowed in some hypothetical future where engines have some
form of runtime feature detection (which they do not right now) any
implementation of such a feature would generate a trap if a module
attempts to execute an instruction the module does not understand. This
deterministic trap behavior would still not fall into the category of
undefined behavior because the trap is deterministic.
For these reasons the `#[target_feature]` attribute is now allowed on
safe functions, but only for WebAssembly targets. This notably enables
the wasm-SIMD intrinsics proposed for stabilization in #74372 to be
marked as safe generally instead of today where they're all `unsafe` due
to the historical implementation of `#[target_feature]` in the compiler.
Reduce the amount of untracked state in TyCtxt
Access to untracked global state may generate instances of #84970.
The GlobalCtxt contains the lowered HIR, the resolver outputs and interners.
By wrapping the resolver inside a query, we make sure those accesses are properly tracked.
As a no_hash query, all dependent queries essentially become `eval_always`,
what they should have been from the beginning.
Fix span of redundant generic arguments
Fixes#71563
Above issue is about lifetime arguments, but generic arguments also have same problem.
This PR fixes both help messages.
This commit updates the compiler's handling of the `#[target_feature]`
attribute when applied to functions on WebAssembly-based targets. The
compiler in general requires that any functions with `#[target_feature]`
are marked as `unsafe` as well, but this commit relaxes the restriction
for WebAssembly targets where the attribute can be applied to safe
functions as well.
The reason this is done is that the motivation for this feature of the
compiler is not applicable for WebAssembly targets. In general the
`#[target_feature]` attribute is used to enhance target CPU features
enabled beyond the basic level for the rest of the compilation. If done
improperly this means that your program could execute an instruction
that the CPU you happen to be running on does not understand. This is
considered undefined behavior where it is unknown what will happen (e.g.
it's not a deterministic `SIGILL`).
For WebAssembly, however, the target is different. It is not possible
for a running WebAssembly program to execute an instruction that the
engine does not understand. If this were the case then the program would
not have validated in the first place and would not run at all. Even if
this were allowed in some hypothetical future where engines have some
form of runtime feature detection (which they do not right now) any
implementation of such a feature would generate a trap if a module
attempts to execute an instruction the module does not understand. This
deterministic trap behavior would still not fall into the category of
undefined behavior because the trap is deterministic.
For these reasons the `#[target_feature]` attribute is now allowed on
safe functions, but only for WebAssembly targets. This notably enables
the wasm-SIMD intrinsics proposed for stabilization in #74372 to be
marked as safe generally instead of today where they're all `unsafe` due
to the historical implementation of `#[target_feature]` in the compiler.
Fix incorrect suggestions for E0605
Fixes#84598. Here is a simplified version of the problem presented in issue #84598:
```Rust
#![allow(unused_variables)]
#![allow(dead_code)]
trait T { fn t(&self) -> i32; }
unsafe fn foo(t: *mut dyn T) {
(t as &dyn T).t();
}
fn main() {}
```
The current output is:
```
error[E0605]: non-primitive cast: `*mut (dyn T + 'static)` as `&dyn T`
--> src/main.rs:7:5
|
7 | (t as &dyn T).t();
| ^^^^^^^^^^^^^ invalid cast
|
help: borrow the value for the cast to be valid
|
7 | (&t as &dyn T).t();
| ^
```
This is incorrect, though: The cast will _not_ be valid when writing `&t` instead of `t`:
```
error[E0277]: the trait bound `*mut (dyn T + 'static): T` is not satisfied
--> t4.rs:7:6
|
7 | (&t as &dyn T).t();
| ^^ the trait `T` is not implemented for `*mut (dyn T + 'static)`
|
= note: required for the cast to the object type `dyn T`
```
The correct suggestion is `&*t`, which I have implemented in this pull request. Of course, this suggestion will always require an unsafe block, but arguably, that's what the user really wants if they're trying to cast a pointer to a reference.
In any case, claiming that the cast will be valid after implementing the suggestion is overly optimistic, as the coercion logic doesn't seem to resolve all nested obligations, i.e. the cast may still be invalid after implementing the suggestion. I have therefore rephrased the suggestion slightly ("consider borrowing the value" instead of "borrow the value for the cast to be valid").
Additionally, I have fixed another incorrect suggestion not mentioned in #84598, which relates to casting immutable references to mutable ones:
```rust
fn main() {
let mut x = 0;
let m = &x as &mut i32;
}
```
currently leads to
```
error[E0605]: non-primitive cast: `&i32` as `&mut i32`
--> t5.rs:3:13
|
3 | let m = &x as &mut i32;
| ^^^^^^^^^^^^^^ invalid cast
|
help: borrow the value for the cast to be valid
|
3 | let m = &mut &x as &mut i32;
| ^^^^
```
which is obviously incorrect:
```
error[E0596]: cannot borrow data in a `&` reference as mutable
--> t5.rs:3:13
|
3 | let m = &mut &x as &mut i32;
| ^^^^^^^ cannot borrow as mutable
```
I've changed the suggestion to a note explaining the problem:
```
error[E0605]: non-primitive cast: `&i32` as `&mut i32`
--> t5.rs:3:13
|
3 | let m = &x as &mut i32;
| ^^^^^^^^^^^^^^ invalid cast
|
note: this reference is immutable
--> t5.rs:3:13
|
3 | let m = &x as &mut i32;
| ^^
note: trying to cast to a mutable reference type
--> t5.rs:3:19
|
3 | let m = &x as &mut i32;
| ^^^^^^^^
```
In this example, it would have been even nicer to suggest replacing `&x` with `&mut x`, but this would be much more complex because we would have to take apart the expression to be cast (currently, we only look at its type), and `&x` could be stored in a variable, where such a suggestion would not even be directly applicable:
```rust
fn main() {
let mut x = 0;
let r = &x;
let m = r as &mut i32;
}
```
My solution covers this case, too.
E0599 suggestions and elision of generic argument if no canditate is found
fixes#81576
changes: In error E0599 (method not found) generic argument are eluded if the method was not found anywhere. If the method was found in another inherent implementation suggest that it was found elsewhere.
Example
```rust
struct Wrapper<T>(T);
struct Wrapper2<T> {
x: T,
}
impl Wrapper2<i8> {
fn method(&self) {}
}
fn main() {
let wrapper = Wrapper(i32);
wrapper.method();
let wrapper2 = Wrapper2{x: i32};
wrapper2.method();
}
```
```
Error[E0599]: no method named `method` found for struct `Wrapper<_>` in the current scope
....
error[E0599]: no method named `method` found for struct `Wrapper2<i32>` in the current scope
...
= note: The method was found for Wrapper2<i8>.
```
I am not very happy with the ```no method named `test` found for struct `Vec<_, _>` in the current scope```. I think it might be better to show only one generic argument `Vec<_>` if there is a default one. But I haven't yet found a way to do that,
Adjust self-type check to require equality
When we encounter `SomeType::<X>::foo`, `self_ty` is `SomeType<X>` and the method is defined in an impl on `SomeType<A>`. Previously, we required simply that `self_ty <: impl_ty`, but this is too lax: we should require equality in order to use the method. This was found as part of unrelated work on never type stabilization, but also fixes one of the wf test cases.
Fix missing lifetimes diagnostics after #83759
In #83759 while rebasing I didn't realize there was a new function for suggesting to add lifetime arguments. It relied on some invariants, namely that if a generic type/trait has angle brackets then it must have some generic argument, which is now no longer true. This PR updates that function to handle the new invariants.
This also adds a new regression test but I'm not sure if that's the correct place for it.
Fixes#85347
