Right now, rustdoc users have an unpleasant situation: they can either
use the new tool lint names (`rustdoc::non_autolinks`) or they can use
the old names (`non_autolinks`). If they use the tool lints, they get a
hard error on stable compilers, because rustc rejects all tool names it
doesn't recognize. If they use the old name, they get a warning to
rename the lint to the new name. The only way to compile without
warnings is to add `#[allow(renamed_removed_lints)]`, which defeats the
whole point of the change: we *want* people to switch to the new name.
To avoid people silencing the lint and never migrating to the tool lint,
this avoids warning about the old name, while still allowing you to use
the new name. Once the new `rustdoc` tool name makes it to the stable
channel, we can change these lints to warn again.
This adds the new lint functions `register_alias` and `register_ignored`
- I didn't see an existing way to do this.
Use delay_span_bug instead of panic in layout_scalar_valid_range
#83054 introduced validation of scalar range attributes, but panicking
code that uses the attribute remained reachable. Use `delay_span_bug`
instead to avoid the ICE.
Fixes#83180.
Allow rustdoc to handle asm! of foreign architectures
This allows rustdoc to process code containing `asm!` for architectures other than the current one. Since this never reaches codegen, we just replace target-specific registers and register classes with a dummy one.
Fixes#82869
StructField -> FieldDef ("field definition")
Field -> ExprField ("expression field", not "field expression")
FieldPat -> PatField ("pattern field", not "field pattern")
Also rename visiting and other methods working on them.
Add a `min_type_alias_impl_trait` feature gate
This new feature gate only permits type alias impl trait to be constrained by function and trait method return types. All other possible constraining sites like const/static types, closure return types and binding types are now forbidden and gated under the `type_alias_impl_trait` and `impl_trait_in_bindings` feature gates (which are both marked as incomplete, as they have various ways to ICE the compiler or cause query cycles where they shouldn't).
r? `@nikomatsakis`
This is best reviewed commit-by-commit
83054 introduced validation of scalar range attributes, but panicking
code that uses the attribute remained reachable. Use `delay_span_bug`
instead to avoid the ICE.
Consider functions to be reachable for code coverage purposes, either
when they reach the code generation directly, or indirectly as inlined
part of another function.
When codegenning code coverage use the instance that coverage data was
originally generated for, to ensure basic level of compatibility with
MIR inlining.
We now lint on *any* use of `procedural-masquerade` crate. While this
crate still exists, its main reverse dependency (`cssparser`) no longer
depends on it. Any crates still depending off should stop doing so, as
it only exists to support very old Rust versions.
If a crate actually needs to support old versions of rustc via
`procedural-masquerade`, then they'll just need to accept the warning
until we remove it entirely (at the same time as the back-compat hack).
The latest version of `procedural-masquerade` does not work with the
latest rustc, but trying to check for the version seems like more
trouble than it's worth.
While working on this, I realized that the `proc-macro-hack` check was
never actually doing anything. The corresponding enum variant in
`proc-macro-hack` is named `Value` or `Nested` - it has never been
called `Input`. Due to a strange Crater issue, the Crater run that
tested adding this did *not* end up testing it - some of the crates that
would have failed did not actually have their tests checked, making it
seem as though the `proc-macro-hack` check was working.
The Crater issue is being discussed at
https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661
Despite the `proc-macro-hack` check not actually doing anything, we
haven't gotten any reports from users about their build being broken.
I went ahead and removed it entirely, since it's clear that no one is
being affected by the `proc-macro-hack` regression in practice.
Don't encode file information for span with a dummy location
Fixes#83112
The location information for a dummy span isn't real, so don't encode
it. This brings the incr comp cache code into line with the Span
`StableHash` impl, which doesn't hash the location information for dummy
spans.
Previously, we would attempt to load the 'original' file from a dummy
span - if the file id changed (e.g. due to being moved on disk), we would get an
ICE, since the Span was still valid due to its hash being unchanged.
Introduce `proc_macro_back_compat` lint, and emit for `time-macros-impl`
Now that future-incompat-report support has landed in nightly Cargo, we
can start to make progress towards removing the various proc-macro
back-compat hacks that have accumulated in the compiler.
This PR introduces a new lint `proc_macro_back_compat`, which results in
a future-incompat-report entry being generated. All proc-macro
back-compat warnings will be grouped under this lint. Note that this
lint will never actually become a hard error - instead, we will remove
the special cases for various macros, which will cause older versions of
those crates to emit some other error.
I've added code to fire this lint for the `time-macros-impl` case. This
is the easiest case out of all of our current back-compat hacks - the
crate was renamed to `time-macros`, so seeing a filename with
`time-macros-impl` guarantees that an older version of the parent `time`
crate is in use.
When Cargo's future-incompat-report feature gets stabilized, affected
users will start to see future-incompat warnings when they build their
crates.
Remove unused `opt_local_def_id_to_hir_id` function
Found while investigating #82933 - all LocalDefIds are expected to have
HirIds, there's no point in pretending otherwise.
Find more invalid doc attributes
- Lint on `#[doc(123)]`, `#[doc("hello")]`, etc.
- Lint every attribute; e.g., will now report two warnings for `#[doc(foo, bar)]`
- Add hyphen to "crate level"
- Display paths like `#[doc(foo::bar)]` correctly instead of as an empty string
Custom error on literal names from other languages
This detects all Java literal types and all single word C data types, and suggests the corresponding Rust literal type.
Update to rustc-rayon 0.3.1
This pulls in rust-lang/rustc-rayon#8 to fix#81425. (h/t `@ammaraskar)`
That revealed weak constraints on `rustc_arena::DropArena`, because its
`DropType` was holding type-erased raw pointers to generic `T`. We can
implement `Send` for `DropType` (under `cfg(parallel_compiler)`) by
requiring all `T: Send` before they're type-erased.
Avoid sorting predicates by `DefId`
Fixes issue #82920
Even if an item does not change between compilation sessions, it may end
up with a different `DefId`, since inserting/deleting an item affects
the `DefId`s of all subsequent items. Therefore, we use a `DefPathHash`
in the incremental compilation system, which is stable in the face of
changes to unrelated items.
In particular, the query system will consider the inputs to a query to
be unchanged if any `DefId`s in the inputs have their `DefPathHash`es
unchanged. Queries are pure functions, so the query result should be
unchanged if the query inputs are unchanged.
Unfortunately, it's possible to inadvertantly make a query result
incorrectly change across compilations, by relying on the specific value
of a `DefId`. Specifically, if the query result is a slice that gets
sorted by `DefId`, the precise order will depend on how the `DefId`s got
assigned in a particular compilation session. If some definitions end up
with different `DefId`s (but the same `DefPathHash`es) in a subsequent
compilation session, we will end up re-computing a *different* value for
the query, even though the query system expects the result to unchanged
due to the unchanged inputs.
It turns out that we have been sorting the predicates computed during
`astconv` by their `DefId`. These predicates make their way into the
`super_predicates_that_define_assoc_type`, which ends up getting used to
compute the vtables of trait objects. This, re-ordering these predicates
between compilation sessions can lead to undefined behavior at runtime -
the query system will re-use code built with a *differently ordered*
vtable, resulting in the wrong method being invoked at runtime.
This PR avoids sorting by `DefId` in `astconv`, fixing the
miscompilation. However, it's possible that other instances of this
issue exist - they could also be easily introduced in the future.
To fully fix this issue, we should
1. Turn on `-Z incremental-verify-ich` by default. This will cause the
compiler to ICE whenver an 'unchanged' query result changes between
compilation sessions, instead of causing a miscompilation.
2. Remove the `Ord` impls for `CrateNum` and `DefId`. This will make it
difficult to introduce ICEs in the first place.
Now that future-incompat-report support has landed in nightly Cargo, we
can start to make progress towards removing the various proc-macro
back-compat hacks that have accumulated in the compiler.
This PR introduces a new lint `proc_macro_back_compat`, which results in
a future-incompat-report entry being generated. All proc-macro
back-compat warnings will be grouped under this lint. Note that this
lint will never actually become a hard error - instead, we will remove
the special cases for various macros, which will cause older versions of
those crates to emit some other error.
I've added code to fire this lint for the `time-macros-impl` case. This
is the easiest case out of all of our current back-compat hacks - the
crate was renamed to `time-macros`, so seeing a filename with
`time-macros-impl` guarantees that an older version of the parent `time`
crate is in use.
When Cargo's future-incompat-report feature gets stabilized, affected
users will start to see future-incompat warnings when they build their
crates.
Fixes#83112
The location information for a dummy span isn't real, so don't encode
it. This brings the incr comp cache code into line with the Span
`StableHash` impl, which doesn't hash the location information for dummy
spans.
Previously, we would attempt to load the 'original' file from a dummy
span - if the file id changed (e.g. due to being moved on disk), we would get an
ICE, since the Span was still valid due to its hash being unchanged.
Rename `rustdoc` to `rustdoc::all`
When rustdoc lints were changed to be tool lints, the `rustdoc` group was removed, leading to spurious warnings like
```
warning: unknown lint: `rustdoc`
```
The lint group still worked when rustdoc ran, since rustdoc added the group itself.
This renames the group to `rustdoc::all` for consistency with `clippy::all` and the rest of the rustdoc lints.
Follow-up to #80527.
r? ``@Manishearth``
This change makes it easier to follow the control flow.
I also moved the end-of-line comments attached to some symbols to before
the symbol listing. This allows rustfmt to format the code; otherwise no
formatting occurs (see rust-lang/rustfmt#4750).
Fixes issue #82920
Even if an item does not change between compilation sessions, it may end
up with a different `DefId`, since inserting/deleting an item affects
the `DefId`s of all subsequent items. Therefore, we use a `DefPathHash`
in the incremental compilation system, which is stable in the face of
changes to unrelated items.
In particular, the query system will consider the inputs to a query to
be unchanged if any `DefId`s in the inputs have their `DefPathHash`es
unchanged. Queries are pure functions, so the query result should be
unchanged if the query inputs are unchanged.
Unfortunately, it's possible to inadvertantly make a query result
incorrectly change across compilations, by relying on the specific value
of a `DefId`. Specifically, if the query result is a slice that gets
sorted by `DefId`, the precise order will depend on how the `DefId`s got
assigned in a particular compilation session. If some definitions end up
with different `DefId`s (but the same `DefPathHash`es) in a subsequent
compilation session, we will end up re-computing a *different* value for
the query, even though the query system expects the result to unchanged
due to the unchanged inputs.
It turns out that we have been sorting the predicates computed during
`astconv` by their `DefId`. These predicates make their way into the
`super_predicates_that_define_assoc_type`, which ends up getting used to
compute the vtables of trait objects. This, re-ordering these predicates
between compilation sessions can lead to undefined behavior at runtime -
the query system will re-use code built with a *differently ordered*
vtable, resulting in the wrong method being invoked at runtime.
This PR avoids sorting by `DefId` in `astconv`, fixing the
miscompilation. However, it's possible that other instances of this
issue exist - they could also be easily introduced in the future.
To fully fix this issue, we should
1. Turn on `-Z incremental-verify-ich` by default. This will cause the
compiler to ICE whenver an 'unchanged' query result changes between
compilation sessions, instead of causing a miscompilation.
2. Remove the `Ord` impls for `CrateNum` and `DefId`. This will make it
difficult to introduce ICEs in the first place.
Issue #82920 showed that the kind of bugs caught by this flag have
soundness implications.
This causes performance regressions of up to 15.2% during incremental
compilation, but this is necessary to catch miscompilations caused by
bugs in query implementations.
rustc_query_system: simplify QueryCache::iter
Minor cleanup to reduce a small amount of complexity and code bloat.
Reduces the number of mono items in rustc_query_impl by 15%.
2229: Handle capturing a reference into a repr packed struct
RFC 1240 states that it is unsafe to capture references into a
packed-struct. This PR ensures that when a closure captures a precise
path, we aren't violating this safety constraint.
To acheive so we restrict the capture precision to the struct itself.
An interesting edge case where we decided to restrict precision:
```rust
struct Foo(String);
let foo: Foo;
let c = || {
println!("{}", foo.0);
let x = foo.0;
}
```
Given how closures get desugared today, foo.0 will be moved into the
closure, making the `println!`, safe. However this can be very subtle
and also will be unsafe if the closure gets inline.
Closes: https://github.com/rust-lang/project-rfc-2229/issues/33
r? `@nikomatsakis`
Allow calling *const methods on *mut values
This allows `*const` methods to be called on `*mut` values.
TODOs:
- [x] ~~Remove debug logs~~ Done.
- [x] ~~I haven't tested, but I think this currently won't work when the `self` value has type like `&&&&& *mut X` because I don't do any autoderefs when probing. To fix this the new code in `rustc_typeck::check::method::probe` needs to reuse `pick_method` somehow as I think that's the function that autoderefs.~~ This works, because autoderefs are done before calling `pick_core`, in `method_autoderef_steps`, called by `probe_op`.
- [x] ~~I should probably move the new `Pick` to `pick_autorefd_method`. If not, I should move it to its own function.~~ Done.
- [ ] ~~Test this with a `Pick` with `to_ptr = true` and `unsize = true`.~~ I think this case cannot happen, because we don't have any array methods with `*mut [X]` receiver. I should confirm that this is true and document this. I've placed two assertions about this.
- [x] ~~Maybe give `(Mutability, bool)` a name and fields~~ I now have a `to_const_ptr` field in `Pick`.
- [x] ~~Changes in `adjust_self_ty` is quite hacky. The problem is we can't deref a pointer, and even if we don't have an adjustment to get the address of a value, so to go from `*mut` to `*const` we need a special case.~~ There's still a special case for `to_const_ptr`, but I'm not sure if we can avoid this.
- [ ] Figure out how `reached_raw_pointer` stuff is used. I suspect only for error messages.
Fixes#80258
Value trees won't have scalar ptr at all, so we need a scalar int printing method anyway. This way we'll be able to share that method between all const representations.
valtree is a version of constants that is inherently safe to be used within types.
This is in contrast to ty::Const which can have different representations of the same value. These representation differences can show up in hashing or equality comparisons, breaking type equality of otherwise equal types.
valtrees do not have this problem.
expand: Do not allocate `Lrc` for `allow_internal_unstable` list unless necessary
This allocation is done for any macro defined in the current crate, or used from a different crate.
EDIT: This also removes an `Lrc` increment from each *use* of such macro, which may be more significant.
Noticed when reviewing https://github.com/rust-lang/rust/pull/82367.
This probably doesn't matter, but let's do a perf run.
Adjust some `#[cfg]`s to take non-Unix non-Windows operating systems into account
This makes compilation to such targets (e.g. `wasm32-wasi`) easier.
cc rust-lang/miri#722bb6d1d0a09 (r48100619)
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`
Shorten `rustc_middle::ty::mod`
Related to #60302.
This PR moves all `Adt*`, `Assoc*`, `Generic*`, and `UpVar*` types to separate files.
This, alongside some `use` reordering, puts `mod.rs` at ~2,200 lines, thus removing the `// ignore-tidy-filelength`.
The particular groups were chosen as they had 4 or more "substantive" members.
This pulls in rust-lang/rustc-rayon#8 to fix#81425. (h/t @ammaraskar)
That revealed weak constraints on `rustc_arena::DropArena`, because its
`DropType` was holding type-erased raw pointers to generic `T`. We can
implement `Send` for `DropType` (under `cfg(parallel_compiler)`) by
requiring all `T: Send` before they're type-erased.
Rollup of 9 pull requests
Successful merges:
- #81309 (always eagerly eval consts in Relate)
- #82217 (Edition-specific preludes)
- #82807 (rustdoc: Remove redundant enableSearchInput function)
- #82924 (WASI: Switch to crt1-command.o to enable support for new-style commands)
- #82949 (Do not attempt to unlock envlock in child process after a fork.)
- #82955 (fix: wrong word)
- #82962 (Treat header as first paragraph for shortened markdown descriptions)
- #82976 (fix error message for copy(_nonoverlapping) overflow)
- #82977 (Rename `Option::get_or_default` to `get_or_insert_default`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
WASI: Switch to crt1-command.o to enable support for new-style commands
This switches Rust's WASI target to use crt1-command.o instead of
crt1.o, which enables support for new-style commands. By default,
new-style commands work the same way as old-style commands, so nothing
immediately changes here, but this will be needed by later changes to
enable support for typed arguments.
See here for more information on new-style commands:
- https://github.com/WebAssembly/wasi-libc/pull/203
- https://reviews.llvm.org/D81689
r? ```@alexcrichton```
Edition-specific preludes
This changes `{std,core}::prelude` to export edition-specific preludes under `rust_2015`, `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*`, but this allows us to add things to the 2021edition prelude soon.
This also changes the compiler to make the automatically injected prelude import dependent on the selected edition.
cc `@rust-lang/libs` `@djc`
Implement RFC 2945: "C-unwind" ABI
## Implement RFC 2945: "C-unwind" ABI
This branch implements [RFC 2945]. The tracking issue for this RFC is #74990.
The feature gate for the issue is `#![feature(c_unwind)]`.
This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19.
### Changes
Further details will be provided in commit messages, but a high-level overview
of the changes follows:
* A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
and `Thiscall` variants, marking whether unwinding across FFI boundaries is
acceptable. The cases where each of these variants' `unwind` member is true
correspond with the `C-unwind`, `system-unwind`, `stdcall-unwind`, and
`thiscall-unwind` ABI strings introduced in RFC 2945 [3].
* This commit adds a `c_unwind` feature gate for the new ABI strings.
Tests for this feature gate are included in `src/test/ui/c-unwind/`, which
ensure that this feature gate works correctly for each of the new ABIs.
A new language features entry in the unstable book is added as well.
* 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.
[RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
Remove the -Zinsert-sideeffect
This removes all of the code we had in place to work-around LLVM's
handling of forward progress. From this removal excluded is a workaround
where we'd insert a `sideeffect` into clearly infinite loops such as
`loop {}`. This code remains conditionally effective when the LLVM
version is earlier than 12.0, which fixed the forward progress related
miscompilations at their root.
This removes all of the code we had in place to work-around LLVM's
handling of forward progress. From this removal excluded is a workaround
where we'd insert a `sideeffect` into clearly infinite loops such as
`loop {}`. This code remains conditionally effective when the LLVM
version is earlier than 12.0, which fixed the forward progress related
miscompilations at their root.
Store HIR attributes in a side table
Same idea as #72015 but for attributes.
The objective is to reduce incr-comp invalidations due to modified attributes.
Notably, those due to modified doc comments.
Implementation:
- collect attributes during AST->HIR lowering, in `LocalDefId -> ItemLocalId -> &[Attributes]` nested tables;
- access the attributes through a `hir_owner_attrs` query;
- local refactorings to use this access;
- remove `attrs` from HIR data structures one-by-one.
Change in behaviour:
- the HIR visitor traverses all attributes at once instead of parent-by-parent;
- attribute arrays are sometimes duplicated: for statements and variant constructors;
- as a consequence, attributes are marked as used after unused-attribute lint emission to avoid duplicate lints.
~~Current bug: the lint level is not correctly applied in `std::backtrace_rs`, triggering an unused attribute warning on `#![no_std]`. I welcome suggestions.~~
RFC 1240 states that it is unsafe to capture references into a
packed-struct. This PR ensures that when a closure captures a precise
path, we aren't violating this safety constraint.
To acheive so we restrict the capture precision to the struct itself.
An interesting edge case:
```rust
struct Foo(String);
let foo: Foo;
let c = || {
println!("{}", foo.0);
let x = foo.0;
}
```
Given how closures get desugared today, foo.0 will be moved into the
closure, making the `println!`, safe. However this can be very subtle
and also will be unsafe if the closure gets inline.
Closes: https://github.com/rust-lang/project-rfc-2229/issues/33
Don't hardcode the `v1` prelude in diagnostics, to allow for new preludes.
Instead of looking for `std::prelude::v1`, this changes the two places where that was hardcoded to look for `std::prelude::<anything>` instead.
This is needed for https://github.com/rust-lang/rust/pull/82217.
r? `@estebank`
Bump tracing-tree dependency
This bump fixes two small rendering things that were annoying me:
* The first level didn't have an opening line
* When wraparound happens, there was no warning, the levels just disappeared. Now there is a line that shows that wraparound is happening
See https://github.com/davidbarsky/tracing-tree/pull/31/files for how the look changes
Add Option::get_or_default
Tracking issue: #82901
The original issue is #55042, which was closed, but for an invalid reason (see discussion there). Opening this to reconsider (I hope that's okay). It seems like the only gap for `Option` being "entry-like".
I ran into a need for this method where I had a `Vec<Option<MyData>>` and wanted to do `vec[n].get_or_default().my_data_method()`. Using an `Option` as an inner component of a data structure is probably where the need for this will normally arise.
Stabilize `unsafe_op_in_unsafe_fn` lint
This makes it possible to override the level of the `unsafe_op_in_unsafe_fn`, as proposed in https://github.com/rust-lang/rust/issues/71668#issuecomment-729770896.
Tracking issue: #71668
r? ```@nikomatsakis``` cc ```@SimonSapin``` ```@RalfJung```
# Stabilization report
This is a stabilization report for `#![feature(unsafe_block_in_unsafe_fn)]`.
## Summary
Currently, the body of unsafe functions is an unsafe block, i.e. you can perform unsafe operations inside.
The `unsafe_op_in_unsafe_fn` lint, stabilized here, can be used to change this behavior, so performing unsafe operations in unsafe functions requires an unsafe block.
For now, the lint is allow-by-default, which means that this PR does not change anything without overriding the lint level.
For more information, see [RFC 2585](https://github.com/rust-lang/rfcs/blob/master/text/2585-unsafe-block-in-unsafe-fn.md)
### Example
```rust
// An `unsafe fn` for demonstration purposes.
// Calling this is an unsafe operation.
unsafe fn unsf() {}
// #[allow(unsafe_op_in_unsafe_fn)] by default,
// the behavior of `unsafe fn` is unchanged
unsafe fn allowed() {
// Here, no `unsafe` block is needed to
// perform unsafe operations...
unsf();
// ...and any `unsafe` block is considered
// unused and is warned on by the compiler.
unsafe {
unsf();
}
}
#[warn(unsafe_op_in_unsafe_fn)]
unsafe fn warned() {
// Removing this `unsafe` block will
// cause the compiler to emit a warning.
// (Also, no "unused unsafe" warning will be emitted here.)
unsafe {
unsf();
}
}
#[deny(unsafe_op_in_unsafe_fn)]
unsafe fn denied() {
// Removing this `unsafe` block will
// cause a compilation error.
// (Also, no "unused unsafe" warning will be emitted here.)
unsafe {
unsf();
}
}
```
### 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`.
### Overview
This commit begins the implementation work for RFC 2945. For more
information, see the rendered RFC [1] and tracking issue [2].
A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
and `Thiscall` variants, marking whether unwinding across FFI
boundaries is acceptable. The cases where each of these variants'
`unwind` member is true correspond with the `C-unwind`,
`system-unwind`, `stdcall-unwind`, and `thiscall-unwind` ABI strings
introduced in RFC 2945 [3].
### Feature Gate and Unstable Book
This commit adds a `c_unwind` feature gate for the new ABI strings.
Tests for this feature gate are included in `src/test/ui/c-unwind/`,
which ensure that this feature gate works correctly for each of the
new ABIs.
A new language features entry in the unstable book is added as well.
### Further Work To Be Done
This commit does not proceed to implement the new unwinding ABIs,
and is intentionally scoped specifically to *defining* the ABIs and
their feature flag.
### One Note on Test Churn
This will lead to some test churn, in re-blessing hash tests, as the
deleted comment in `src/librustc_target/spec/abi.rs` mentioned,
because we can no longer guarantee the ordering of the `Abi`
variants.
While this is a downside, this decision was made bearing in mind
that RFC 2945 states the following, in the "Other `unwind` Strings"
section [3]:
> More unwind variants of existing ABI strings may be introduced,
> with the same semantics, without an additional RFC.
Adding a new variant for each of these cases, rather than specifying
a payload for a given ABI, would quickly become untenable, and make
working with the `Abi` enum prone to mistakes.
This approach encodes the unwinding information *into* a given ABI,
to account for the future possibility of other `-unwind` ABI
strings.
### Ignore Directives
`ignore-*` directives are used 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`.
This would otherwise fail on some targets, see:
fcf697f902
### Footnotes
[1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
[2]: https://github.com/rust-lang/rust/issues/74990
[3]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#other-unwind-abi-strings
