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.
Rollup of 8 pull requests
Successful merges:
- #87645 (Properly find owner of closure in THIR unsafeck)
- #87646 (Fix a parser ICE on invalid `fn` body)
- #87652 (Validate that naked functions are never inlined)
- #87685 (Write docs for SyncOnceCell From and Default impl)
- #87693 (Add `aarch64-apple-ios-sim` as a possible target to the manifest)
- #87708 (Add convenience method for handling ipv4-mapped addresses by canonicalizing them)
- #87711 (Correct typo)
- #87716 (Allow generic SIMD array element type)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Fix a parser ICE on invalid `fn` body
Fixes#87635
A better fix would add a check for `fn` body on `expected_one_of_not_found` but I haven't come up with a graceful way. Any idea?
r? ```@oli-obk``` ```@estebank```
Properly find owner of closure in THIR unsafeck
Previously, when encountering a closure in a constant, the THIR unsafeck gets invoked on the owner of the constant instead of the constant itself, producing cycles.
Supersedes #87492. ```@FabianWolff``` thanks for your work on that PR, I copied your test file and added you as a co-author.
Fixes#87414.
r? ```@oli-obk```
Support negative numbers in Literal::from_str
proc_macro::Literal has allowed negative numbers in a single literal token ever since Rust 1.29, using https://doc.rust-lang.org/stable/proc_macro/struct.Literal.html#method.isize_unsuffixed and similar constructors.
```rust
let lit = proc_macro::Literal::isize_unsuffixed(-10);
```
However, the suite of constructors on Literal is not sufficient for all use cases, for example arbitrary precision floats, or custom suffixes in FFI macros.
```rust
let lit = proc_macro::Literal::f64_unsuffixed(0.101001000100001000001000000100000001); // :(
let lit = proc_macro::Literal::i???_suffixed(10ulong); // :(
```
For those, macros construct the literal using from_str instead, which preserves arbitrary precision, custom suffixes, base, and digit grouping.
```rust
let lit = "0.101001000100001000001000000100000001".parse::<Literal>().unwrap();
let lit = "10ulong".parse::<Literal>().unwrap();
let lit = "0b1000_0100_0010_0001".parse::<Literal>().unwrap();
```
However, until this PR it was not possible to construct a literal token that is **both** negative **and** preserving of arbitrary precision etc.
This PR fixes `Literal::from_str` to recognize negative integer and float literals.
Implement a `explicit_generic_args_with_impl_trait` feature gate
Implements #83701
When this gate is enabled, explicit generic arguments can be specified even if `impl Trait` is used in argument position. Generic arguments can only be specified for explicit generic parameters but not for the synthetic type parameters from `impl Trait`
So code like this will be accepted:
```rust
#![feature(explicit_generic_args_with_impl_trait)]
fn foo<T: ?Sized>(_f: impl AsRef<T>) {}
fn main() {
foo::<str>("".to_string());
}
```
CTFE: throw unsupported error when partially overwriting a pointer
Currently, during CTFE, when a write to memory would overwrite parts of a pointer, we make the remaining parts of that pointer "uninitialized". This is probably not what users expect, so if this ever happens they will be quite confused about why some of the data just vanishes for seemingly no good reason.
So I propose we change this to abort CTFE when that happens, to at last avoid silently doing the wrong thing.
Cc https://github.com/rust-lang/rust/issues/87184
Our CTFE test suite still seems to pass. However, we should probably crater this, and I want to do some tests with Miri as well.
rfc3052 followup: Remove authors field from Cargo manifests
Since RFC 3052 soft deprecated the authors field, hiding it from
crates.io, docs.rs, and making Cargo not add it by default, and it is
not generally up to date/useful information for contributors, we may as well
remove it from crates in this repo.
When this gate is enabled, explicit generic arguments can be specified even
if `impl Trait` is used in argument position. Generic arguments can only be
specified for explicit generic parameters but not for the synthetic type
parameters from `impl Trait`
Bump bootstrap compiler to 1.55
Changing the cfgs for stdarch is missing, but my understanding is that we don't need to do it as part of this PR?
r? `@Mark-Simulacrum`
Bail on any found recursion when expanding opaque types
Fixes#87450. More of a bandaid because it does not fix the exponential complexity of the type folding used for opaque type expansion.
Suggest `br` if the unknown string prefix `rb` is found
Currently, for the following code:
```rust
fn main() {
rb"abc";
}
```
we issue the following suggestion:
```
help: consider inserting whitespace here
|
2 | rb "abc";
| --
```
With my changes (only in edition 2021, where unknown prefixes became an error), I get:
```
help: use `br` for a raw byte string
|
2 | br"abc";
| ^^
```
Add a hint that the expressions produce a value
Fixes#85913
The second commit is semi-_unrelated_ but it allows us to run the related tests just on `src/test/ui/lint`.
Trait upcasting coercion (part1)
This revives the first part of earlier PR #60900 .
It's not very clear to me which parts of that pr was design decisions, so i decide to cut it into pieces and land them incrementally. This allows more eyes on the details.
This is the first part, it adds feature gates, adds feature gates tests, and implemented the unsize conversion part.
(I hope i have dealt with the `ExistentialTraitRef` values correctly...)
The next part will be implementing the pointer casting.
Rollup of 9 pull requests
Successful merges:
- #86072 (Cross compiling rustc_llvm on Darwin requires zlib.)
- #87385 (Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by default)
- #87547 (Add missing examples for NonNull)
- #87557 (Fix issue with autofix for ambiguous associated function from Rust 2021 prelude when struct is generic)
- #87559 (Tweak borrowing suggestion in `for` loop)
- #87596 (Add warning when whitespace is not skipped after an escaped newline)
- #87606 (Add some TAIT-related regression tests)
- #87609 (Add docs about performance and `Iterator::map` to `[T; N]::map`)
- #87616 (Fix missing word in rustdoc book)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Add warning when whitespace is not skipped after an escaped newline
Fixes issue #87318, also simplifies issue #87319.
* Add support to the lexer to emit warnings as well as errors.
* Emit a warning when a string literal contains an escaped newline, but when (some of) the whitespace on the next line is not skipped due to it being non-ASCII.
Fix issue with autofix for ambiguous associated function from Rust 2021 prelude when struct is generic
Fixes#86940
The test cases and associated issue should make it clear what specifically this is meant to fix. The fix is slightly hacky in that we check against the literal source code of the call site for the presence of `<` in order to determine if the user has included the generics for the struct (meaning we don't need to include them for them).
r? ``@nikomatsakis``
Make `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` warn by default
This PR makes the `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint warn by default.
To avoid showing a large number of un-actionable warnings to users, we only enable the lint for macros defined in the same crate. This ensures that users will be able to fix the warning by simply removing a semicolon.
In the future, I'd like to enable this lint unconditionally, and eventually make it into a hard error in a future edition. This PR is a step towards that goal.
