Use `rtassert!` instead of `assert!` from the child process after fork() in std::sys::unix::process::Command::spawn()
As discussed in #73894, `assert!` panics on failure, which is not signal-safe, and `rtassert!` is a suitable replacement.
Fixes#73894.
r? @Amanieu @cuviper @joshtriplett
library: Forward compiler-builtins "mem" feature
This fixes https://github.com/rust-lang/wg-cargo-std-aware/issues/53
Now users will be able to do:
```
cargo build -Zbuild-std=core -Zbuild-std-features=compiler-builtins-mem
```
and correctly get the Rust implemenations for `memcpy` and friends.
Signed-off-by: Joe Richey <joerichey@google.com>
Ensure that all LLVM components requested by tests are available on CI
Addresses https://github.com/rust-lang/rust/pull/75064#issuecomment-667722652
I used an environment variable because passing a command line option all the way from CI to compiletest would be just too much hassle for this task.
I added a new variable, but any of the already existing ones defined by CI could be used instead.
r? @Mark-Simulacrum
Add support for cmse_nonsecure_entry attribute
This pull request adds the `cmse_nonsecure_entry` attribute under an unstable feature.
I was not sure if it was fine for me to send directly the pull-request or if I should submit a RFC first. I was told on Zulip that it was fine to do so but please close it if I need first submit a RFC or follow another process instead.
The `cmse_nonsecure_entry` attribute is a LLVM attribute that will be available in LLVM 11. I plan to rebase on the [upgrade PR](https://github.com/rust-lang/rust/pull/73526) once merged to make this one compile.
This attribute modifies code generation of the function as explained [here](https://developer.arm.com/documentation/ecm0359818/latest/) to make it work with the TrustZone-M hardware feature. This feature is only available on `thumbv8m` targets so I created an error for that if one tries to use this attribute for another target.
I added this attribute in Rust as any other LLVM attribute are added but since this one is target-dependent I am not sure if it was the best thing to do. Please indicate me if you think of other ways, like isolating target-dependent attributes together.
----------------
Tracking issue: https://github.com/rust-lang/rust/issues/75835
Don't warn if the config file is somewhere other than `config.toml`
Previously, `config.config` was always hardcoded as `"config.toml"`.
I thought that it was being overridden with the actual value later, but
it turns out `flags.config` was being completely discarded. This keeps
`config.config` in sync with `flags.config`.
Fixes https://github.com/rust-lang/rust/issues/77293
r? `@Mark-Simulacrum`
cc `@davidtwco`
This patch adds support for the LLVM cmse_nonsecure_entry attribute.
This is a target-dependent attribute that only has sense for the
thumbv8m Rust targets.
You can find more information about this attribute here:
https://developer.arm.com/documentation/ecm0359818/latest/
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
Secure entry functions do not support if arguments are passed on the
stack. An "unsupported" diagnostic will be emitted by LLVM if that is
the case.
This commits adds support in Rust for that diagnostic so that an error
will be output if that is the case!
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
WASI does not match `cfg(unix)`, but its paths are Unix-like (`/some/path`) and don't have Windows-like prefixes.
Without this change, `is_absolute` for paths like `/some/path` was returning `false`on a WASI target, which is obviously not true and undesirable.
SipHasher128 implements short_write in an endian-independent way, yet
its write_xxx Hasher trait methods undo this endian-independence by byte
swapping the integer inputs on big-endian hardware. StableHasher then
adds endian-independence back by also byte-swapping on big-endian
hardware prior to invoking SipHasher128.
This double swap may have the appearance of being a no-op, but is in
fact by design. In particular, we really do want SipHasher128 to be
platform-dependent, in order to be consistent with the libstd SipHasher.
Try to clarify this intent. Also, add and update a couple of unit tests.
This helper function was meant to reduce code duplication between
const-checking pre- and post-drop-elaboration. Most of the functionality
is only relevant for the pre-drop-elaboration pass.
bootstrap: Always build for host, even when target is given
This changes the behavior from *not* building for host whenever an
explicit target is specified. I find this much less confusing.
You can still disable host steps by passing an explicit empty list for
host.
Fixes#76990.
r? `@Mark-Simulacrum`
