* The WASI targets deal with the `main` symbol a bit differently than
native so some `codegen` and `assembly` tests have been ignored.
* All `ignore-emscripten` directives have been updated to
`ignore-wasm32` to be more clear that all wasm targets are ignored and
it's not just Emscripten.
* Most `ignore-wasm32-bare` directives are now gone.
* Some ignore directives for wasm were switched to `needs-unwind`
instead.
* Many `ignore-wasm32*` directives are removed as the tests work with
WASI as opposed to `wasm32-unknown-unknown`.
This commit rewrites a number of `run-make` tests centered around wasm
to instead use `rmake.rs` and additionally use the `wasm32-wasip1`
target instead of `wasm32-unknown-unknown`. Testing no longer requires
Node.js and additionally uses the `wasmparser` crate from crates.io to
parse outputs and power assertions.
This commit renames the current `wasm32-wasi-preview1-threads` target to
`wasm32-wasip1-threads`. The need for this rename is a bit unfortunate
as the previous name was chosen in an attempt to be future-compatible
with other WASI targets. Originally this target was proposed to be
`wasm32-wasi-threads`, and that's what was originally implemented in
wasi-sdk as well. After discussion though and with the plans for the
upcoming component-model target (now named `wasm32-wasip2`) the
"preview1" naming was chosen for the threads-based target. The WASI
subgroup later decided that it was time to drop the "preview"
terminology and recommends "pX" instead, hence previous PRs to add
`wasm32-wasip2` and rename `wasm32-wasi` to `wasm32-wasip1`.
So, with all that history, the "proper name" for this target is
different than its current name, so one way or another a rename is
required. This PR proposes renaming this target cold-turkey, unlike
`wasm32-wasi` which is having a long transition period to change its
name. The threads-based target is predicted to see only a fraction of
the traffic of `wasm32-wasi` due to the unstable nature of the WASI
threads proposal itself.
While I was here I updated the in-tree documentation in the target spec
file itself as most of the documentation was copied from the original
WASI target and wasn't as applicable to this target.
Also, as an aside, I can at least try to apologize for all the naming
confusion here, but this is hopefully the last WASI-related rename.
unix_sigpipe: Replace `inherit` with `sig_dfl` in syntax tests
The `sig_dfl` variant of the attribute is the most likely variant to be stabilized first, and thus to become the "most allowed" variant of the attribute. Because of this, it is the most appropriate variant to use in syntax tests, because even if the most allowed variant is used, the compiler shall still emit errors if it e.g. is used in the wrong places.
r? ``@davidtwco`` who already [approved ](https://github.com/rust-lang/rust/pull/120832#pullrequestreview-1875075341) this commit in https://github.com/rust-lang/rust/pull/120832.
It would be nice to land the last preparatory commit of that PR before we begin to [rename ](https://github.com/rust-lang/rust/pull/120832#issuecomment-1987023484) things which will of course create a lot of code conflicts.
Use ptradd for vtable indexing
Extension of #121665.
After this, the only remaining usages of GEP are [this](cd81f5b27e/compiler/rustc_codegen_llvm/src/intrinsic.rs (L909-L920)) kinda janky Emscription EH code, which I'll change in a future PR, and array indexing / pointer offsets, where there isn't yet a canonical `ptradd` form. (Out of curiosity I tried converting the latter to `ptradd(ptr, mul(size, index))`, but that causes codegen regressions right now.)
r? `@nikic`
Revision-related tweaks for next-solver tests
1. Add `ignore-compare-mode-next-solver` to any test that already has explicit `current next` revisions, since the test failures when testing with `--compare-mode=next-solver` will be false positives.
2. Explicitly add revisions to a handful of tests where we expect behavior to diverge.
r? lcnr
Add tests (and a bit of cleanup) for interior mut handling in promotion and const-checking
Basically these are the parts of https://github.com/rust-lang/rust/pull/121786 that can be salvaged.
r? ``@oli-obk``
Fix type resolution of associated const equality bounds (take 2)
Instead of trying to re-resolve the type of assoc const bindings inside the `type_of` query impl in an incomplete manner, transfer the already (correctly) resolved type from `add_predicates_for_ast_type_binding` to `type_of`/`anon_type_of` through query feeding.
---
Together with #118668 (merged) and #121258, this supersedes #118360.
Fixes#118040.
r? ``@ghost``
Run a single huge par_body_owners instead of many small ones after each other.
This improves parallel rustc parallelism by avoiding the bottleneck after each individual `par_body_owners` (because it needs to wait for queries to finish, so if there is one long running one, a lot of cores will be idle while waiting for the single query).
This improves parallel rustc parallelism by avoiding the bottleneck after each individual `par_body_owners` (because it needs to wait for queries to finish, so if there is one long running one, a lot of cores will be idle while waiting for the single query).
Allow multiple `impl Into<{D,Subd}iagMessage>` parameters in a function.
The internal diagnostic lint currently only allows one, because that was all that occurred in practice. But rust-lang/rust-clippy/pull/12453 wants to introduce functions with more than one, and this limitation is getting in the way.
r? `@Nilstrieb`
Expose the Freeze trait again (unstably) and forbid implementing it manually
non-emoji version of https://github.com/rust-lang/rust/pull/121501
cc #60715
This trait is useful for generic constants (associated consts of generic traits). See the test (`tests/ui/associated-consts/freeze.rs`) added in this PR for a usage example. The builtin `Freeze` trait is the only way to do it, users cannot work around this issue.
It's also a useful trait for building some very specific abstrations, as shown by the usage by the `zerocopy` crate: https://github.com/google/zerocopy/issues/941
cc ```@RalfJung```
T-lang signed off on reexposing this unstably: https://github.com/rust-lang/rust/pull/121501#issuecomment-1969827742
The internal diagnostic lint currently only allows one, because that was
all that occurred in practice. But rust-lang/rust-clippy/pull/12453
wants to introduce functions with more than one, and this limitation is
getting in the way.
The `sig_dfl` variant of the attribute is the most likely variant to be
stabilized first, and thus to become the "most allowed" variant of the
attribute. Because of this, it is the most appropriate variant to use in
syntax tests, because even if the most allowed variant is used, the
compiler shall still emit errors if it e.g. is used in the wrong places.
Stop using LLVM struct types for byval/sret
For `byval` and `sret`, the type has no semantic meaning, only the size matters\*†. Using `[N x i8]` is a more direct way to specify that we want `N` bytes, and avoids relying on LLVM's struct layout.
\*: The alignment would matter, if we didn't explicitly specify it. From what I can tell, we always specified the alignment for `sret`; for `byval`, we didn't until #112157.
†: For `byval`, the hidden copy may be impacted by padding in the LLVM struct type, i.e. padding bytes may not be copied. (I'm not sure if this is done today, but I think it would be legal.) But we manually pad our LLVM struct types specifically to avoid there ever being LLVM-visible padding, so that shouldn't be an issue.
Split out from #121577.
r? `@nikic`
diagnostics: Do not suggest using `#[unix_sigpipe]` without a value
Remove `Word` from the `unix_sigpipe` attribute template so that plain `#[unix_sigpipe]` is not included in suggestions of valid forms of the attribute. Also re-arrange diagnostics code slightly to avoid duplicate diagnostics.
Tracking issue is https://github.com/rust-lang/rust/issues/97889.
MIR printing: print the path of uneval'd const
Currently it just prints `const _` which makes it impossible to say which constant is being referred to.
Also refer to promoteds in a consistent way; previously MIR printing would do
```
promoted[0] in C1: &Option<Cell<i32>> = {
// ...
}
```
Now that should be
```
const C1::promoted[0]: &Option<Cell<i32>> = {
// ...
}
```
We don't seem to have a test for that so I tried it by hand, it seems to work:
```
const main::promoted[12]: &[&str; 3] = {
let mut _0: &[&str; 3];
let mut _1: [&str; 3];
let mut _2: &str;
let mut _3: &str;
let mut _4: &str;
let mut _5: &str;
bb0: {
_3 = const "b";
_2 = &(*_3);
_5 = const "c";
_4 = &(*_5);
_1 = [const "a", move _2, move _4];
_0 = &_1;
return;
}
}
```
Detect typos for compiletest test directives
Checks directives against a known list of compiletest directives collected during migration from legacy-style compiletest directives. A suggestion for the best matching known directive will be made if an invalid directive is found.
This PR does not attempt to implement checks for Makefile directives because they still have the problem of regular comments and directives sharing the same comment prefix `#`.
Closes#83551.
Remove `Word` from the `unix_sigpipe` attribute template so that plain
`#[unix_sigpipe]` is not included in suggestions of valid forms of the
attribute. Also re-arrange diagnostics code slightly to avoid duplicate
diagnostics.
Fixing shellcheck comments on lvi test script
Running `shellcheck` on `tests/run-make/x86_64-fortanix-unknown-sgx-lvi/script.sh` gives plenty of warnings. This PR fixes those issues. For completeness: #121683 fixes another warning as well
Update a test to support Symbol Mangling V0
Note that since this is a symbol from `std`, overriding the symbol mangling version via the `compile-flags` directive does not work.
Distinguish between library and lang UB in assert_unsafe_precondition
As described in https://github.com/rust-lang/rust/pull/121583#issuecomment-1963168186, `assert_unsafe_precondition` now explicitly distinguishes between language UB (conditions we explicitly optimize on) and library UB (things we document you shouldn't do, and maybe some library internals assume you don't do).
`debug_assert_nounwind` was originally added to avoid the "only at runtime" aspect of `assert_unsafe_precondition`. Since then the difference between the macros has gotten muddied. This totally revamps the situation.
Now _all_ preconditions shall be checked with `assert_unsafe_precondition`. If you have a precondition that's only checkable at runtime, do a `const_eval_select` hack, as done in this PR.
r? RalfJung
Vec::try_with_capacity
Related to #91913
Implements try_with_capacity for `Vec`, `VecDeque`, and `String`. I can follow it up with more collections if desired.
`Vec::try_with_capacity()` is functionally equivalent to the current stable:
```rust
let mut v = Vec::new();
v.try_reserve_exact(n)?
```
However, `try_reserve` calls non-inlined `finish_grow`, which requires old and new `Layout`, and is designed to reallocate memory. There is benefit to using `try_with_capacity`, besides syntax convenience, because it generates much smaller code at the call site with a direct call to the allocator. There's codegen test included.
It's also a very desirable functionality for users of `no_global_oom_handling` (Rust-for-Linux), since it makes a very commonly used function available in that environment (`with_capacity` is used much more frequently than all `(try_)reserve(_exact)`).
