Prevent compiler stack overflow for deeply recursive code
I was unable to write a test that
1. runs in under 1s
2. overflows on my machine without this patch
The following reproduces the issue, but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`.
```rust
// compile-pass
#![recursion_limit="1000000"]
macro_rules! chain {
(EE $e:expr) => {$e.sin()};
(RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))};
(Z $e:expr) => {chain!(RECURSE EE $e)};
(Y $e:expr) => {chain!(RECURSE Z $e)};
(X $e:expr) => {chain!(RECURSE Y $e)};
(A $e:expr) => {chain!(RECURSE X $e)};
(B $e:expr) => {chain!(RECURSE A $e)};
(C $e:expr) => {chain!(RECURSE B $e)};
// causes overflow on x86_64 linux
// less than 1 second until overflow on test machine
// after overflow has been fixed, takes 30s to compile :/
(D $e:expr) => {chain!(RECURSE C $e)};
(E $e:expr) => {chain!(RECURSE D $e)};
(F $e:expr) => {chain!(RECURSE E $e)};
// more than 10 seconds
(G $e:expr) => {chain!(RECURSE F $e)};
(H $e:expr) => {chain!(RECURSE G $e)};
(I $e:expr) => {chain!(RECURSE H $e)};
(J $e:expr) => {chain!(RECURSE I $e)};
(K $e:expr) => {chain!(RECURSE J $e)};
(L $e:expr) => {chain!(RECURSE L $e)};
}
fn main() {
let x = chain!(D 42.0_f32);
}
```
fixes#55471fixes#41884fixes#40161fixes#34844fixes#32594
cc @alexcrichton @rust-lang/compiler
I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.
Define UB in float-to-int casts to saturate
This closes#10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.
- Round to zero, and representable values cast directly.
- `NaN` goes to 0
- Values beyond the limits of the type are saturated to the "nearest value"
(essentially rounding to zero, in some sense) in the integral type, so e.g.
`f32::INFINITY` would go to `{u,i}N::MAX.`
Add Option to Force Unwind Tables
When panic != unwind, `nounwind` is added to all functions for a target.
This can cause issues when a panic happens with RUST_BACKTRACE=1, as
there needs to be a way to reconstruct the backtrace. There are three
possible sources of this information: forcing frame pointers (for which
an option exists already), debug info (for which an option exists), or
unwind tables.
Especially for embedded devices, forcing frame pointers can have code
size overheads (RISC-V sees ~10% overheads, ARM sees ~2-3% overheads).
In production code, it can be the case that debug info is not kept, so it is useful
to provide this third option, unwind tables, that users can use to
reconstruct the call stack. Reconstructing this stack is harder than
with frame pointers, but it is still possible.
---
This came up in discussion on #69890, and turned out to be a fairly simple addition.
r? @hanna-kruppe
When panic != unwind, `nounwind` is added to all functions for a target.
This can cause issues when a panic happens with RUST_BACKTRACE=1, as
there needs to be a way to reconstruct the backtrace. There are three
possible sources of this information: forcing frame pointers (for which
an option exists already), debug info (for which an option exists), or
unwind tables.
Especially for embedded devices, forcing frame pointers can have code
size overheads (RISC-V sees ~10% overheads, ARM sees ~2-3% overheads).
In code, it can be the case that debug info is not kept, so it is useful
to provide this third option, unwind tables, that users can use to
reconstruct the call stack. Reconstructing this stack is harder than
with frame pointers, but it is still possible.
This commit adds a compiler option which allows a user to force the
addition of unwind tables. Unwind tables cannot be disabled on targets
that require them for correctness, or when using `-C panic=unwind`.
Miri: unleash all feature gates
IMO it is silly to unleash features that do not even have a feature gate yet, but not unleash features that do. The only thing this achieves is making unleashed mode annoying to use as we have to figure out the feature flags to enable (and not always do the error messages say what that flag is).
Given that the point of `-Z unleash-the-miri-inside-of-you` is to debug the Miri internals, I see no good reason for this extra hurdle. I cannot imagine a situation where we'd use that flag, realize the program also requires some feature gate, and then be like "oh I guess if this feature is unstable I will do something else". Instead, we'll always just add that flag to the code as well, so requiring the flag achieves nothing.
r? @oli-obk @ecstatic-morse
Fixes https://github.com/rust-lang/rust/issues/71630
Rename `bitcode-in-rlib` option to `embed-bitcode`
This commit finishes work first pioneered in #70458 and started in #71528.
The `-C bitcode-in-rlib` option, which has not yet reached stable, is
renamed to `-C embed-bitcode` since that more accurately reflects what
it does now anyway. Various tests and such are updated along the way as
well.
This'll also need to be backported to the beta channel to ensure we
don't accidentally stabilize `-Cbitcode-in-rlib` as well.
This commit finishes work first pioneered in #70458 and started in #71528.
The `-C bitcode-in-rlib` option, which has not yet reached stable, is
renamed to `-C embed-bitcode` since that more accurately reflects what
it does now anyway. Various tests and such are updated along the way as
well.
This'll also need to be backported to the beta channel to ensure we
don't accidentally stabilize `-Cbitcode-in-rlib` as well.
Remove support for self-opening
This was only used for linkage test cases, which is already covered by
the [run-make-fulldeps/symbol-visibility test](https://github.com/rust-lang/rust/blob/master/src/test/run-make-fulldeps/symbol-visibility/Makefile) -- which fairly extensively makes
sure we're correctly exporting the right symbols at the right visibility (for
various Rust crate types).
This fixes#10379 and resolves#10356 by removing the test case (and underlying support in the compiler). AFAICT, the better way to test visibility is via nm, like the symbol visibility test. It seems like that's sufficient; I suspect that given that we don't use this we should just drop it (android is tier 2 anyway). But happy to hear otherwise.
Replace thread_local with generator resume arguments in box_region.
Fixes#68922.
Continuation of #70622. Added a short doc, hope it makes sense.
r? @jonas-schievink
This was only used for linkage test cases, which is already covered by
the run-make-fulldeps/symbol-visibility test -- which fairly extensively makes
sure we're correctly exporting the right symbols at the right visibility (for
various Rust crate types).
In the code, test, and docs, because it makes it much easier to find
things.
Other than adding the comments about alphabetical order, this commit
only moves things around.
This lets us specify the default at the options declaration point,
instead of using `.unwrap(default)` or `None | Some(default)` at some
use point far away. It also makes the code more concise.
Do not lose or reorder user-provided linker arguments
Linker arguments are potentially order-dependent, so the order in which `-C link-arg` and `-C link-args` options are passed to `rustc` should be preserved when they are passed further to the linker.
Also, multiple `-C link-args` options are now appended to each other rather than overwrite each other.
In other words, `-C link-arg=a -C link-args="b c" -C link-args="d e" -C link-arg=f` is now passed as `"a" "b" "c" "d" "e" "f"` and not as `"d" "e" "a" "f"`.
Addresses https://github.com/rust-lang/rust/pull/70505#issuecomment-606780163.
Add `-Z dump-mir-dataflow` flag for dumping dataflow results visualization
Previously, to visualize the results of a MIR dataflow pass, one had to add a `#[rustc_mir(borrowck_graphviz_postflow)]` attribute to functions of interest. However, there is no way to specify this attribute on closures and generators, so it was impossible to view results for these MIR bodies.
This PR adds a flag, `-Z dump-mir-dataflow`, which will output the dataflow results for any functions specified in `-Z dump-mir` to the output directory specified by `-Z dump-mir-dir`. This behavior is modeled on the `-Z dump-mir-graphviz` flag.
use is_empty() instead of len comparison (clippy::len_zero)
use if let instead of while let loop that never loops (clippy::never_loop)
remove redundant returns (clippy::needless_return)
remove redundant closures (clippy::redundant_closure)
use if let instead of match and wildcard pattern (clippy::single_match)
don't repeat field names redundantly (clippy::redundant_field_names)
