Add a new `wasm32-wasip3` target to Rust
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group.
As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a
more-ready-than-nonexistent state by the time this happens in December.
For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably:
* The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup.
* Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use.
* Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target.
These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change.
[`wasip3` crate]: https://crates.io/crates/wasip3
kcfi: only reify trait methods when dyn-compatible
fixes https://github.com/rust-lang/rust/issues/146853
Only generate a `ReifyShim` for trait method calls if the trait is dyn-compatible.
Until now kcfi would generate a `ReifyShim` whenever a trait method was cast to a function pointer. But technically the shim is only needed for dyn-compatible traits (where the method might end up in a vtable).
Up to this point that was only slightly inefficient, but in combination with c-variadic trait methods it is wrong. For c-variadic trait methods the generated shim is incorrect, and that is why c-variadic methods make a trait no longer dyn-compatible: we should simply never generate a `ReifyShim` that is c-variadic.
With this change the documentation on `ReifyReason` is now actually correct:
> If KCFI is enabled, creating a function pointer from a method on a dyn-compatible trait. This includes the case of converting `::call`-like methods on closure-likes to function pointers.
cc ```@maurer``` ```@workingjubilee```
r? ```@rcvalle```
Prevent downstream `impl DerefMut for Pin<LocalType>`
The safety requirements for [`PinCoerceUnsized`](https://doc.rust-lang.org/stable/std/pin/trait.PinCoerceUnsized.html) are essentially that the type does not have a malicious `Deref` or `DerefMut` impl. However, the `Pin` type is fundamental, so the end-user can provide their own implementation of `DerefMut` for `Pin<&SomeLocalType>`, so it's possible for `Pin` to have a malicious `DerefMut` impl. This unsoundness is known as rust-lang/rust#85099.
Unfortunately, this means that the implementation of `PinCoerceUnsized` for `Pin` is currently unsound. To fix that, modify the impl so that it becomes impossible for downstream crates to provide their own implementation of `DerefMut` for `Pin` by abusing a hidden struct that is not fundamental.
This PR is a breaking change, but it fixesrust-lang/rust#85099. The PR supersedes rust-lang/rust#144896.
r? lcnr
don't panic on extern with just multiple quotes in the name
Continues rust-lang/rust#147377.
That PR fixed ICE when the extern name was a single quote `"'"`, but multiple quotes like `"''"` cause the same problem.
I had a random revelation that the trimming can remove more than one quote.
r? ``@nnethercote``
Improve diagnostics: update note and add help message
I moved the content from the note to a help message, as it seemed more appropriate there, and then added new information to the note(`Modules are usually placed outside of blocks, at the top level of the file`)!
resolve: rust-lang/rust#147314
test: Subtract code_offset from width for ui_testing
`annotate-snippets` does not have a "UI test" mode like `rustc`, [where the code offset is not subtracted from the column width](https://github.com/rust-lang/rust/blob/f34ba774c78ea32b7c40598b8ad23e75cdac42a6/compiler/rustc_errors/src/emitter.rs#L1985-L1987). This makes it so `annotate-snippets` will shift the output for some very long tests 5 - 7 columns to the left. As part of my work to have `rustc` use `annotate-snippets`, and to reduce the test differences between the two, I figured it would be best if `rustc` started subtracting the code offset from the width as well.
The first commit exists to keep the test output changes of adding a new line to a test separate from adding the `--diagnostic-width` flag in the second commit. This makes it easier to verify that adding the flag does not affect the test's output.
[Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/annotate-snippets.20hurdles)
GVN: Use a VnIndex in Address projection.
The current implementation of address projections is inconsistent. Indexing semantically relies on the index' value, but the implementation uses the index' place. This PR fixes that by using `ProjectionElem<VnIndex, Ty<'tcx>>` instead of the raw `PlaceElem<'tcx>`.
This is a more principled fix than the workaround in https://github.com/rust-lang/rust/pull/145030.
compiler: Hint at multiple crate versions if trait impl is for wrong ADT
If a user does e.g.
impl From<Bar> for foo::Foo
and get a compilation error about that `From<Bar>` is not implemented for `Foo`, check if multiple versions of the crate with `Foo` is present in the dependency graph. If so, give a hint about it.
Note that a test is added as a separate commit so it is easy to see what effect the fix has on the emitted error message.
This can be seen as a continuation of rust-lang/rust#124944.
I think this closes RUST-71693 but I haven't checked since it lacks a minimal reproducer. If this gets merged I'll ask that reporter if this fix works for them.
## Real world example
I encountered this case in the wild and didn't realize I had multiple versions of a crate in my dependency graph. So I was a bit confused at first. For reference, here is what that looked like.
<details>
<summary>Click to expand</summary>
### Before fix
```
error[E0277]: the trait bound `lambda_http::lambda_runtime::Diagnostic: From<Error>` is not satisfied
--> src/main.rs:73:5
|
73 | lambda_http::run(service_fn(handle_event)).await
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `From<Error>` is not implemented for `lambda_http::lambda_runtime::Diagnostic`
|
= help: the following other types implement trait `From<T>`:
`lambda_http::lambda_runtime::Diagnostic` implements `From<&str>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError + Send + Sync>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Infallible>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<lambda_runtime::deserializer::DeserializeError>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::io::Error>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::string::String>`
= note: required for `Error` to implement `Into<lambda_http::lambda_runtime::Diagnostic>`
note: required by a bound in `lambda_http::run`
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_http-0.17.0/src/lib.rs:199:26
|
194 | pub async fn run<'a, R, S, E>(handler: S) -> Result<(), Error>
| --- required by a bound in this function
...
199 | E: std::fmt::Debug + Into<Diagnostic>,
| ^^^^^^^^^^^^^^^^ required by this bound in `run`
error[E0277]: the trait bound `lambda_http::lambda_runtime::Diagnostic: From<Error>` is not satisfied
--> src/main.rs:73:48
|
73 | lambda_http::run(service_fn(handle_event)).await
| ^^^^^ the trait `From<Error>` is not implemented for `lambda_http::lambda_runtime::Diagnostic`
|
= help: the following other types implement trait `From<T>`:
`lambda_http::lambda_runtime::Diagnostic` implements `From<&str>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError + Send + Sync>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Infallible>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<lambda_runtime::deserializer::DeserializeError>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::io::Error>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::string::String>`
= note: required for `Error` to implement `Into<lambda_http::lambda_runtime::Diagnostic>`
note: required by a bound in `lambda_http::run`
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_http-0.17.0/src/lib.rs:199:26
|
194 | pub async fn run<'a, R, S, E>(handler: S) -> Result<(), Error>
| --- required by a bound in this function
...
199 | E: std::fmt::Debug + Into<Diagnostic>,
| ^^^^^^^^^^^^^^^^ required by this bound in `run`
For more information about this error, try `rustc --explain E0277`.
error: could not compile `auto-merge-dependabot-pull-requests-webhook` (bin "auto-merge-dependabot-pull-requests-webhook") due to 2 previous errors
```
### After fix
```
Compiling auto-merge-dependabot-pull-requests-webhook v0.1.0 (/home/martin/src/auto-merge-dependabot-prs/rust-webhook)
error[E0277]: the trait bound `lambda_http::lambda_runtime::Diagnostic: From<Error>` is not satisfied
--> src/main.rs:73:5
|
73 | lambda_http::run(service_fn(handle_event)).await
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `From<Error>` is not implemented for `lambda_http::lambda_runtime::Diagnostic`
|
help: item with same name found
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_runtime-0.13.0/src/diagnostic.rs:43:1
|
43 | pub struct Diagnostic {
| ^^^^^^^^^^^^^^^^^^^^^
= note: perhaps two different versions of crate `lambda_runtime` are being used?
= help: the following other types implement trait `From<T>`:
`lambda_http::lambda_runtime::Diagnostic` implements `From<&str>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError + Send + Sync>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Infallible>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<lambda_runtime::deserializer::DeserializeError>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::io::Error>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::string::String>`
= note: required for `Error` to implement `Into<lambda_http::lambda_runtime::Diagnostic>`
note: required by a bound in `lambda_http::run`
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_http-0.17.0/src/lib.rs:199:26
|
194 | pub async fn run<'a, R, S, E>(handler: S) -> Result<(), Error>
| --- required by a bound in this function
...
199 | E: std::fmt::Debug + Into<Diagnostic>,
| ^^^^^^^^^^^^^^^^ required by this bound in `run`
error[E0277]: the trait bound `lambda_http::lambda_runtime::Diagnostic: From<Error>` is not satisfied
--> src/main.rs:73:48
|
73 | lambda_http::run(service_fn(handle_event)).await
| ^^^^^ the trait `From<Error>` is not implemented for `lambda_http::lambda_runtime::Diagnostic`
|
help: item with same name found
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_runtime-0.13.0/src/diagnostic.rs:43:1
|
43 | pub struct Diagnostic {
| ^^^^^^^^^^^^^^^^^^^^^
= note: perhaps two different versions of crate `lambda_runtime` are being used?
= help: the following other types implement trait `From<T>`:
`lambda_http::lambda_runtime::Diagnostic` implements `From<&str>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError + Send + Sync>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Infallible>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<lambda_runtime::deserializer::DeserializeError>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::io::Error>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::string::String>`
= note: required for `Error` to implement `Into<lambda_http::lambda_runtime::Diagnostic>`
note: required by a bound in `lambda_http::run`
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_http-0.17.0/src/lib.rs:199:26
|
194 | pub async fn run<'a, R, S, E>(handler: S) -> Result<(), Error>
| --- required by a bound in this function
...
199 | E: std::fmt::Debug + Into<Diagnostic>,
| ^^^^^^^^^^^^^^^^ required by this bound in `run`
For more information about this error, try `rustc --explain E0277`.
error: could not compile `auto-merge-dependabot-pull-requests-webhook` (bin "auto-merge-dependabot-pull-requests-webhook") due to 2 previous errors
```
</details>
try-job: dist-various-1
try-job: aarch64-msvc-1
support link modifier `as-needed` for raw-dylib-elf
This pull request:
* emits `-Wl,--as-needed` instead of `-Wl,--no-as-needed` for `raw-dylib-elf`, keeping it consistent with `dylib`
* allows combination of link kind `raw-dylib` and link modifier `as-needed`, thus allowing free choice of behavior
r? `@bjorn3`
cc https://github.com/rust-lang/rust/issues/135694
cc https://github.com/rust-lang/rust/issues/99424
If a user does e.g.
impl From<Bar> for foo::Foo
and get a compilation error about that `From<Bar>` is not implemented
for `Foo`, check if multiple versions of the crate with `Foo` is present
in the dependency graph. If so, give a hint about it.
I encountered this case in the wild and didn't realize I had multiple
versions of a crate in my dependency graph. So I was a bit confused at
first. This fix will make life easier for others.
ignore power alignment rule on unions
fixes https://github.com/rust-lang/rust/issues/147348
The power alignment rule only applies to the non-first field of a struct, and so should not apply to unions at all.
The current code also does not consider enums (whose fields might be, morally, structs). Given that C does not actually have ADTs like this it's probably fine from a compatibility perspective, but I'll leave that to the powerpc folks.
cc `@daltenty` `@gilamn5tr`
r? compiler
cg_llvm: Remove inherent methods from several LLVM FFI types
This is mainly motivated by rust-lang/rust#142897, which proposes to move the LLVM FFI bindings out of `rustc_codegen_llvm` and into `rustc_llvm`, which is arguably the more correct place for them from a linking perspective.
---
In order to perform that migration, all of the types used in FFI signatures also need to be moved. However, several of those types have inherent methods that convert from backend-independent types to LLVM FFI types.
Moving the inherent methods as-is would require adding a lot of otherwise-unnecessary dependencies to `rustc_llvm`. And we can't leave them behind as-is, because inherent methods can't be defined in another crate.
Therefore, this PR replaces several of those inherent methods with either extension trait methods or free functions.
This will make `-Zbuild-std` automatically build the right crates, notably not building `std` by default, which will both be useful for users and also fix the build for https://does-it-build.noratrieb.dev.
Make `fmt::Write` a diagnostic item
I'm working on an enhancement to [`clippy::format_push_string`](https://rust-lang.github.io/rust-clippy/master/index.html#format_push_string), which would suggest an autofix to replace `push_str`/`+=` with `write!`. But that could require importing `std::fmt::Write`, and so I need this diagnostic item to check if it's already in scope.
The reason I called it `FmtWrite` and not just `Write` is that there's already an `IoWrite` defined.
Mark `PatternTypo` suggestion as maybe incorrect
Partial fix for https://github.com/rust-lang/rust/issues/147303.
`@rustbot` label A-diagnostics A-suggestion-diagnostics D-invalid-suggestion
Do not assert that a change in global cache only happens when concurrent
Fixesrust-lang/trait-system-refactor-initiative#234
I think it should just be safe to remove this assert (rather than delaying a bug). If the previous and current result are the same, I wouldn't expect issues.
r? lcnr
interpret `#[used]` as `#[used(compiler)]` on illumos
helps rust-lang/rust#146169 not be as painful: fixes the illumos regression in rust-lang/rust#140872, but `#[used(linker)]` is still erroneous on illumos generally.
illumos' `ld` does not support a flag like either SHF_GNU_RETAIN or SHF_SUNW_NODISCARD, so there is no way to communicate `#[used(linker)]` for that target. Setting `USED_LINKER` to try results in LLVM setting SHF_SUNW_NODISCARD for Solaris-like targets, which is an unknown section header flag for illumos `ld` and prevents sections from being merged that otherwise would.
As a motivating example, the `inventory` crate produces `#[used]` items to merge into `.init_array`. Because those items have an unknown section header flag they are not merged with the default `.init_array` with `frame_dummy`, and end up never executed.
Downgrading `#[used]` to `#[used(compiler)]` on illumos keeps so-attributed items as preserved as they had been before https://github.com/rust-lang/rust/pull/140872. As was the case before that change, because rustc passes `-z ignore` to illumos `ld`, it's possible that `used` sections are GC'd at link time. https://github.com/rust-lang/rust/issues/146169 describes this unfortunate circumstance.
----
as it turns out, `tests/ui/attributes/used_with_archive.rs` had broken on `x86_64-unknown-illumos`, and this patch fixes it. the trials and tribulations of tier 2 :(
r? ````@Noratrieb```` probably?
Matthias Krüger