Name the captured upvars for closures/generators in debuginfo
Previously, debuggers print closures as something like
```
y::main::closure-0 (0x7fffffffdd34)
```
The pointer actually references to an upvar. It is not very obvious, especially for beginners.
It's because upvars don't have names before, as they are packed into a tuple. This PR names the upvars, so we can expect to see something like
```
y::main::closure-0 {_captured_ref__b: 0x[...]}
```
r? `@tmandry`
Discussed at https://github.com/rust-lang/rust/pull/84752#issuecomment-831639489 .
This commit intends to fill out some of the remaining pieces of the
C-unwind ABI. This has a number of other changes with it though to move
this design space forward a bit. Notably contained within here is:
* On `panic=unwind`, the `extern "C"` ABI is now considered as "may
unwind". This fixes a longstanding soundness issue where if you
`panic!()` in an `extern "C"` function defined in Rust that's actually
UB because the LLVM representation for the function has the `nounwind`
attribute, but then you unwind.
* Whether or not a function unwinds now mainly considers the ABI of the
function instead of first checking the panic strategy. This fixes a
miscompile of `extern "C-unwind"` with `panic=abort` because that ABI
can still unwind.
* The aborting stub for non-unwinding ABIs with `panic=unwind` has been
reimplemented. Previously this was done as a small tweak during MIR
generation, but this has been moved to a separate and dedicated MIR
pass. This new pass will, for appropriate functions and function
calls, insert a `cleanup` landing pad for any function call that may
unwind within a function that is itself not allowed to unwind. Note
that this subtly changes some behavior from before where previously on
an unwind which was caught-to-abort it would run active destructors in
the function, and now it simply immediately aborts the process.
* The `#[unwind]` attribute has been removed and all users in tests and
such are now using `C-unwind` and `#![feature(c_unwind)]`.
I think this is largely the last piece of the RFC to implement.
Unfortunately I believe this is still not stabilizable as-is because
activating the feature gate changes the behavior of the existing `extern
"C"` ABI in a way that has no replacement. My thinking for how to enable
this is that we add support for the `C-unwind` ABI on stable Rust first,
and then after it hits stable we change the behavior of the `C` ABI.
That way anyone straddling stable/beta/nightly can switch to `C-unwind`
safely.
- Closures in external crates may get compiled in because of
monomorphization. We should store names of captured variables
in `optimized_mir`, so that they are written into the metadata
file and we can use them to generate debuginfo.
- If there are breakpoints inside closures, the names of captured
variables stored in `optimized_mir` can be used to print them.
Now the name is more precise when disjoint fields are captured.
This commit implements the idea of a new ABI for the WebAssembly target,
one called `"wasm"`. This ABI is entirely of my own invention
and has no current precedent, but I think that the addition of this ABI
might help solve a number of issues with the WebAssembly targets.
When `wasm32-unknown-unknown` was first added to Rust I naively
"implemented an abi" for the target. I then went to write `wasm-bindgen`
which accidentally relied on details of this ABI. Turns out the ABI
definition didn't match C, which is causing issues for C/Rust interop.
Currently the compiler has a "wasm32 bindgen compat" ABI which is the
original implementation I added, and it's purely there for, well,
`wasm-bindgen`.
Another issue with the WebAssembly target is that it's not clear to me
when and if the default C ABI will change to account for WebAssembly's
multi-value feature (a feature that allows functions to return multiple
values). Even if this does happen, though, it seems like the C ABI will
be guided based on the performance of WebAssembly code and will likely
not match even what the current wasm-bindgen-compat ABI is today. This
leaves a hole in Rust's expressivity in binding WebAssembly where given
a particular import type, Rust may not be able to import that signature
with an updated C ABI for multi-value.
To fix these issues I had the idea of a new ABI for WebAssembly, one
called `wasm`. The definition of this ABI is "what you write
maps straight to wasm". The goal here is that whatever you write down in
the parameter list or in the return values goes straight into the
function's signature in the WebAssembly file. This special ABI is for
intentionally matching the ABI of an imported function from the
environment or exporting a function with the right signature.
With the addition of a new ABI, this enables rustc to:
* Eventually remove the "wasm-bindgen compat hack". Once this
ABI is stable wasm-bindgen can switch to using it everywhere.
Afterwards the wasm32-unknown-unknown target can have its default ABI
updated to match C.
* Expose the ability to precisely match an ABI signature for a
WebAssembly function, regardless of what the C ABI that clang chooses
turns out to be.
* Continue to evolve the definition of the default C ABI to match what
clang does on all targets, since the purpose of that ABI will be
explicitly matching C rather than generating particular function
imports/exports.
Naturally this is implemented as an unstable feature initially, but it
would be nice for this to get stabilized (if it works) in the near-ish
future to remove the wasm32-unknown-unknown incompatibility with the C
ABI. Doing this, however, requires the feature to be on stable because
wasm-bindgen works with stable Rust.
make changes to liveness to use closure_min_captures
use different span
borrow check uses new structures
rename to CapturedPlace
stop using upvar_capture in regionck
remove the bridge
cleanup from rebase + remove the upvar_capture reference from mutability_errors.rs
remove line from livenes test
make our unused var checking more consistent
update tests
adding more warnings to the tests
move is_ancestor_or_same_capture to rustc_middle/ty
update names to reflect the closures
add FIXME
check that all captures are immutable borrows before returning
add surrounding if statement like the original
move var out of the loop and rename
Co-authored-by: Logan Mosier <logmosier@gmail.com>
Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
Eagerly construct bodies of THIR
With this PR:
- the THIR is no longer constructed lazily, but is entirely built before being passed to the MIR Builder
- the THIR is now allocated in arenas instead of `Box`es
However, this PR doesn't make any changes to the way patterns are constructed: they are still boxed, and exhaustiveness checking is unchanged.
Implements MCP rust-lang/compiler-team#409.
Closesrust-lang/project-thir-unsafeck#1.
r? `@ghost` cc `@nikomatsakis` `@oli-obk`
### Add debug assertion to check `AbiDatas` ordering
This makes a small alteration to `Abi::index`, so that we include a
debug assertion to check that the index we are returning corresponds
with the same abi in our data array.
This will help prevent ordering bugs in the future, which can
manifest in rather strange errors.
### Using exhaustive ABI matches
This slightly modifies the changes from our previous commits,
favoring exhaustive matches in place of `_ => ...` fall-through
arms.
This should help with maintenance in the future, when additional
ABI's are added, or when existing ABI's are modified.
### List all `-unwind` ABI's in unstable book
This updates the `c-unwind` page in the unstable book to list _all_
of the other ABI strings that are introduced by this feature gate.
Now, all of the ABI's specified by RFC 2945 are shown.
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
### Changes
This commit implements unwind ABI's, specified in RFC 2945.
We adjust the `rustc_middle::ty::layout::fn_can_unwind` function,
used to compute whether or not a `FnAbi` object represents a
function that should be able to unwind when `panic=unwind` is in
use.
Changes are also made to
`rustc_mir_build::build::should_abort_on_panic` so that the
function ABI is used to determind whether it should abort, assuming
that the `panic=unwind` strategy is being used, and no explicit
unwind attribute was provided.
### Tests
Unit tests, checking that the behavior is correct for `C-unwind`,
`stdcall-unwind`, `system-unwind`, and `thiscall-unwind`, are
included. These alternative `unwind` ABI strings are specified in
RFC 2945, in the "_Other `unwind` ABI strings_" section.
Additionally, a test case is included to assert that the LLVM IR
generated for an external function defined with the `C-unwind` ABI
will be appropriately labeled with the `nounwind` LLVM attribute
when the `panic=abort` compilation flag is used.
### Ignore Directives
This commit uses `ignore-*` directives in two of our `*-unwind` ABI
test cases.
Specifically, the `stdcall-unwind` and `thiscall-unwind` test cases
ignore architectures that do not support `stdcall` and `thiscall`,
respectively.
These directives are cribbed from
`src/test/ui/c-variadic/variadic-ffi-1.rs` for `stdcall`, and
`src/test/ui/extern/extern-thiscall.rs` for `thiscall`.
When `capture_disjoint_fields` is not enabled, checking if the root variable
binding is mutable would suffice.
However with the feature enabled, the captured place might be mutable
because it dereferences a mutable reference.
This PR computes the mutability of each capture after capture analysis
in rustc_typeck. We store this in `ty::CapturedPlace` and then use
`ty::CapturedPlace::mutability` in mir_build and borrow_check.
[mir-opt] Allow debuginfo to be generated for a constant or a Place
Prior to this commit, debuginfo was always generated by mapping a name
to a Place. This has the side-effect that `SimplifyLocals` cannot remove
locals that are only used for debuginfo because their other uses have
been const-propagated.
To allow these locals to be removed, we now allow debuginfo to point to
a constant value. The `ConstProp` pass detects when debuginfo points to
a local with a known constant value and replaces it with the value. This
allows the later `SimplifyLocals` pass to remove the local.
- Closures now use closure_min_captures to figure out captured paths
- Build upvar_mutbls using closure_min_captures
- Change logic in limit_capture_mutability to differentiate b/w
capturing parent's local variable or capturing a variable that is
captured by the parent (in case of nested closure) using PlaceBase.
Co-authored-by: Roxane Fruytier <roxane.fruytier@hotmail.com>
Prior to this commit, debuginfo was always generated by mapping a name
to a Place. This has the side-effect that `SimplifyLocals` cannot remove
locals that are only used for debuginfo because their other uses have
been const-propagated.
To allow these locals to be removed, we now allow debuginfo to point to
a constant value. The `ConstProp` pass detects when debuginfo points to
a local with a known constant value and replaces it with the value. This
allows the later `SimplifyLocals` pass to remove the local.
Replace `(Body, DefId)` with `Body` where possible
Follow-up to #77430.
I `grep`-ed for parameter lists in which a `Body` appeared within a few lines of a `DefId`, so it's possible that I missed some cases, but this should be pretty complete. Most of these changes were mechanical, but there's a few places where I started calling things "caller" and "callee" when multiple `DefId`s were in-scope at once. Also, we should probably have a helper function on `Body` that returns a `LocalDefId`. I can do that in this PR or in a follow-up.
