* 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 updates compiletest to automatically compare test output
with subsets if a `--runner` argument is configured. Runners might
inject extra information on failures, for example a WebAssembly runtime
printing a wasm stack trace, which won't be in the output of a native
runtime. The output with a `--runner` argument, however, should still
have all the native output present.
This commit updates the libtest conditionals to use `std::time::Instant`
on WASI targets where it's implemented. Previously all wasm targets
wouldn't use this type.
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.
Add metadata to targets
follow up to #121905 and #122157
This adds four pieces of metadata to every target:
- description
- tier
- host tools
- std
This information is currently scattered across target docs and both
- not machine readable, making validation harder
- sometimes subtly encoding by the table it's in, causing mistakes and making it harder to review changes to the properties
By putting it in the compiler, we improve this. Later, we will use this canonical information to generate target documentation from it.
I used find-replace for all the `description: None`.
One thing I'm not sure about is the behavior for the JSON. It doesn't really make sense that custom targets supply this information, especially the tier. But for the roundtrip tests, we do need to print and parse it. Maybe emit a warning when a custom target provides the metadata key? Either way, I don't think that's important right now, this PR should get merged ASAP or it will conflict all over the place.
r? davidtwco
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`
Add `target.*.runner` configuration for targets
This commit adds a `runner` field configuration to `config.toml` for specifying a wrapper executable when executing binaries for a target. This is pulled out of #122036 where a WebAssembly runtime is used, for example, to execute tests for `wasm32-wasip1`.
The name "runner" here is chosen to match Cargo's `CARGO_*_RUNNER` configuration, and to make things a bit more consistent this additionally renames compiletest's `--runtool` argument to `--runner`.
std::threads: revisit stack address calculation on netbsd.
like older linux glibc versions, we need to get the guard size
and increasing the stack's bottom address accordingly.
skip sanity check for non-host targets in `check` builds
For `check` builds, since we only need to perform a sanity check on the host target, this patch skips target sanity checks on non-host targets.
For more context, see https://github.com/rust-lang/rust/issues/121519#issuecomment-1974836049
cc ``@saethlin``
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
Win10: Use `GetSystemTimePreciseAsFileTime` directly
On Windows 10 we can use `GetSystemTimePreciseAsFileTime` directly instead of lazy loading it (with a fallback).
Add slice::try_range
This adds a fallible version of the unstable `slice::range` (tracking: #76393) which is highly requested in the tracking issue.
Hoping this can slide by without an ACP (since the feature is already being tracked), but let me know otherwise.
Convert `Unix{Datagram,Stream}::{set_}passcred()` to per-OS traits
These methods are the pre-stabilized API for obtaining peer credentials from an `AF_UNIX` socket, part of the `unix_socket_ancillary_data` feature.
Their current behavior is to get/set one of the `SO_PASSCRED` (Linux), `LOCAL_CREDS_PERSISTENT` (FreeBSD), or `LOCAL_CREDS` (NetBSD) socket options. On other targets the `{set_}passcred()` methods do not exist.
There are two problems with this approach:
1. Having public methods only exist for certain targets isn't permitted in a stable `std` API.
2. These options have generally similar purposes, but they are non-POSIX and their details can differ in subtle and surprising ways (such as whether they continue to be set after the next call to `recvmsg()`).
Splitting into OS-specific extension traits is the preferred solution to both problems.
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.
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`
Rollup of 9 pull requests
Successful merges:
- #122275 (disable OOM test in Miri)
- #122276 (io::Read trait: make it more clear when we are adressing implementations vs callers)
- #122277 (BorrowedCursor docs clarification)
- #122286 (use Instance::expect_resolve() instead of unwraping Instance::resolve())
- #122290 (MIR printing: print the path of uneval'd const)
- #122293 (diagnostics: Do not suggest using `#[unix_sigpipe]` without a value)
- #122297 (bootstrap: document what the triples in 'Build' mean)
- #122302 (docs: Correct ptr/ref verbiage in SliceIndex docs.)
- #122304 (fix metadata for dyn-star in new solver)
r? `@ghost`
`@rustbot` modify labels: rollup
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;
}
}
```
BorrowedCursor docs clarification
If one reads the `BorrowedCursor` docs without having seen `BorrowedBuf` before, it is quite easy to assume that "unfilled" and "uninit" are synonyms.
io::Read trait: make it more clear when we are adressing implementations vs callers
Inspired by [this](https://github.com/rust-lang/rust/issues/72186#issuecomment-1987076295) comment.
For some reason we only have that `buf` warning in `read` and `read_exact`, even though it affects a bunch of other functions of this trait as well. It doesn't seem worth copy-pasting the same text everywhere though so I did not change this.
This adds four pieces of metadata to every target:
- description
- tier
- host tools
- std
This information is currently scattered across target docs and both
- not machine readable, making validation harder
- sometimes subtly encoding by the table it's in, causing mistakes and
making it harder to review changes to the properties
By putting it in the compiler, we improve this. Later, we will use this
canonical information to generate target documentation from it.
