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.
Rollup of 7 pull requests
Successful merges:
- #76454 (UI to unit test for those using Cell/RefCell/UnsafeCell)
- #76474 (Add option to pass a custom codegen backend from a driver)
- #76711 (diag: improve closure/generic parameter mismatch)
- #77170 (Remove `#[rustc_allow_const_fn_ptr]` and add `#![feature(const_fn_fn_ptr_basics)]`)
- #77194 (Add doc alias for iterator fold)
- #77288 (fix building libstd for Miri on macOS)
- #77295 (Update unstable-book: Fix ABNF in inline assembly docs)
Failed merges:
r? `@ghost`
Add doc alias for iterator fold
fold is known in python and javascript as reduce,
not sure about inject but it was written in doc there.
This was my first confusion when coming into rust, I somehow cannot find where is reduce, sometimes I still forget that it is known as `fold`.
Remove `#[rustc_allow_const_fn_ptr]` and add `#![feature(const_fn_fn_ptr_basics)]`
`rustc_allow_const_fn_ptr` was a hack to work around the lack of an escape hatch for the "min `const fn`" checks in const-stable functions. Now that we have co-opted `allow_internal_unstable` for this purpose, we no longer need a bespoke attribute.
Now this functionality is gated under `const_fn_fn_ptr_basics` (how concise!), and `#[allow_internal_unstable(const_fn_fn_ptr_basics)]` replaces `#[rustc_allow_const_fn_ptr]`. `const_fn_fn_ptr_basics` allows function pointer types to appear in the arguments and locals of a `const fn` as well as function pointer casts to be performed inside a `const fn`. Both of these were allowed in constants and statics already. Notably, this does **not** allow users to invoke function pointers in a const context. Presumably, we will use a nicer name for that (`const_fn_ptr`?).
r? @oli-obk
diag: improve closure/generic parameter mismatch
Fixes#51154.
This PR improves the diagnostic when a type parameter is expected and a closure is found, noting that each closure has a distinct type and therefore could not always match the caller-chosen type of the parameter.
r? @estebank
Add option to pass a custom codegen backend from a driver
This allows the driver to pass information to the codegen backend. For example the headcrab debugger may in the future want to use cg_clif to JIT code to be injected in the debuggee. This would PR make it possible to tell cg_clif which symbol can be found at which address and to tell it to inject the JITed code into the right process.
This PR may also help with https://github.com/rust-lang/miri/pull/1540 by allowing miri to provide a codegen backend that only emits metadata and doesn't perform any codegen.
cc @nbaksalyar (headcrab)
cc @RalfJung (miri)
UI to unit test for those using Cell/RefCell/UnsafeCell
Helps with #76268.
I'm working on all files using `Cell` and moving them to unit tests when possible.
r? @matklad
[mir-opt] Introduce a new flag to enable experimental/unsound mir opts
This implements part of https://github.com/rust-lang/compiler-team/issues/319. The exact name of this flag was not decided as part of that MCP and some people expressed that it should include "unsound" in some way.
I've chosen to use `enable-experimental-unsound-mir-opts` as the name. While long, I don't think that matters too much as really it will only be used by some mir-opt tests. If you object or have a better name, please leave a comment!
r? `@oli-obk`
cc `@rust-lang/wg-mir-opt` `@RalfJung`
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`.
Add missing definitions required by the sparc-unknown-linux-gnu target
This PR adds a few missing definitions required by sparc-unknown-linux-target which were discovered during build tests.
Deduplicate and generalize some (de/)serializer impls
I noticed this while implementing #77227 and getting a "not implemented for [T; 16]" error. There's likely more things we can deduplicate in this file, but I didn't need any additional changes.
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>
LVI hardening tests
Mitigating the speculative execution LVI attack against SGX enclaves requires compiler changes (i.e., adding lfences). This pull requests adds various tests to check if this happens correctly.
Reopen standard file descriptors when they are missing on Unix
The syscalls returning a new file descriptors generally return lowest-numbered
file descriptor not currently opened, without any exceptions for those
corresponding to stdin, sdout, or stderr.
Previously when any of standard file descriptors has been closed before starting
the application, operations on std::io::{stderr,stdin,stdout} were likely to
either succeed while being performed on unrelated file descriptor, or fail with
EBADF which is silently ignored.
Avoid the issue by using /dev/null as a replacement when the standard file
descriptors are missing.
The implementation is based on the one found in musl. It was selected among a
few others on the basis of the lowest overhead in the case when all descriptors
are already present (measured on GNU/Linux).
Closes#57728.
Closes#46981.
Closes#60447.
Benefits:
* Makes applications robust in the absence of standard file descriptors.
* Upholds IntoRawFd / FromRawFd safety contract (which was broken previously).
Drawbacks:
* Additional syscall during startup.
* The standard descriptors might have been closed intentionally.
* Requires /dev/null.
Alternatives:
* Check if stdin, stdout, stderr are opened and provide no-op substitutes in std::io::{stdin,stdout,stderr} without reopening them directly.
* Leave the status quo, expect robust applications to reopen them manually.
Replace `discriminant_switch_effect` with more general version
#68528 added a new edge-specific effect for `SwitchInt` terminators, `discriminant_switch_effect`, to the dataflow framework. While this accomplished the short-term goal of making drop elaboration more precise, it wasn't really useful in other contexts: It only supported `SwitchInt`s on the discriminant of an `enum` and did not allow effects to be applied along the "otherwise" branch. In const-propagation, for example, arbitrary edge-specific effects for the targets of a `SwitchInt` can be used to remember the value a `match` scrutinee must have in each arm.
This PR replaces `discriminant_switch_effect` with a more general `switch_int_edge_effects` method. The new method has a slightly different interface from the other edge-specific effect methods (e.g. `call_return_effect`). This divergence is explained in the new method's documentation, and reading the changes to the various dataflow impls as well as `direction.rs` should further clarify things. This PR should not change behavior.
The syscalls returning a new file descriptors generally use
lowest-numbered file descriptor not currently opened, without any
exceptions for those corresponding to the standard streams.
Previously when any of standard streams has been closed before starting
the application, operations on std::io::{stderr,stdin,stdout} objects
were likely to operate on other logically unrelated file resources
opened afterwards.
Avoid the issue by reopening the standard streams when they are closed.
Small improvements in liveness pass
* Remove redundant debug logging (`add_variable` already contains logging).
* Remove redundant fields for a number of live nodes and variables.
* Delay conversion from a symbol to a string until linting.
* Inline contents of specials struct.
* Remove unnecessary local variable exit_ln.
* Use newtype_index for Variable and LiveNode.
* Access live nodes directly through self.lnks[ln].
No functional changes intended (except those related to the logging).
