Rollup of 8 pull requests #81475
Closed
Rollup of 8 pull requests #81475
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is relied on by wundergraph.
Prevents LateContext::maybe_typeck_results() from returning data in a nested item without a body. Consequently, LateContext::qpath_res is less likely to ICE when called in a nested item. Would have prevented rust-lang/rust-clippy#4545, presumably.
Actually fulfills the documented guarantees.
Add expected error Add comment Tweak comment wording Fix after rebase to updated master Fix after rebase to updated master Distinguish mutation in normal and move closures Tweak error message Fix error message for nested closures Refactor code showing mutated upvar in closure Remove debug assert B
### 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.
### Footnotes
[1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
[2]: rust-lang#74990
[3]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#other-unwind-abi-strings
### 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.
### 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.
Co-authored-by: Niko Matsakis <niko@alum.mit.edu>
### Changes
This commit addresses some test failures that now occur in the
following two tests:
* no_std-alloc-error-handler-custom.rs
* no_std-alloc-error-handler-default.rs
Each test now defines a `rust_eh_personality` extern function, in
the same manner as shown in the "Writing an executable without
stdlib" section of the `lang_items` documentation here:
https://doc.rust-lang.org/unstable-book/language-features/lang-items.html#writing-an-executable-without-stdlib
Without this change, these tests would fail to compile due to a
linking error explaining that there was an "undefined reference
to `rust_eh_personality'."
### Changes
This commit introduces some new fixtures to the `run-make-fulldeps`
test suite.
* c-unwind-abi-hello-world: A simple "happy path" fixture. This
involves calling from Rust, into C, and back into a Rust
`C-unwind` function.
* c-unwind-abi-catch-panic: Exercise unwinding a panic. This
reuses much of the same code, but instead catches a panic and
downcasts it into an integer.
* c-unwind-abi-catch-lib-panic: This is similar to the previous
`*catch-panic` test, however in this case the Rust code that
panics resides in a separate crate.
### Changes
This is a small commit, updating 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>
This commit addresses a tidy error that currently occurs on this branch:
```
tidy error:
following path contains more than 1458 entries,
you should move the test to some relevant
subdirectory (current: 1459): /checkout/src/test/ui
```
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
The angle brackets were not rendered, so code like this:
some_func: for<'a> fn(val: &'a i32) -> i32
would be rendered as:
some_func: fn'a(val: &'a i32) -> i32
However, rendering with angle brackets is still invalid syntax:
some_func: fn<'a>(val: &'a i32) -> i32
so now it renders correctly as:
some_func: for<'a> fn(val: &'a i32) -> i32
-----
However, note that this code:
some_trait: dyn for<'a> Trait<'a>
will still render as:
some_trait: dyn Trait<'a>
which is not invalid syntax, but is still unclear. Unfortunately I think
it's hard to fix that case because there isn't enough information in the
`rustdoc::clean::Type` that this code operates on. Perhaps that case can
be fixed in a later PR.
cc rust-lang#79813 This PR adds an allow-by-default future-compatibility lint `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS`. It fires when a trailing semicolon in a macro body is ignored due to the macro being used in expression position: ```rust macro_rules! foo { () => { true; // WARN } } fn main() { let val = match true { true => false, _ => foo!() }; } ``` The lint takes its level from the macro call site, and can be allowed for a particular macro by adding `#[allow(semicolon_in_expressions_from_macros)]`. The lint is set to warn for all internal rustc crates (when being built by a stage1 compiler). After the next beta bump, we can enable the lint for the bootstrap compiler as well.
…945-c-unwind-abi, r=Amanieu Implement RFC 2945: "C-unwind" ABI ## Implement RFC 2945: "C-unwind" ABI This branch implements [RFC 2945]. The tracking issue for this RFC is rust-lang#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
…micolon, r=petrochenkov Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint cc rust-lang#79813 This PR adds an allow-by-default future-compatibility lint `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS`. It fires when a trailing semicolon in a macro body is ignored due to the macro being used in expression position: ```rust macro_rules! foo { () => { true; // WARN } } fn main() { let val = match true { true => false, _ => foo!() }; } ``` The lint takes its level from the macro call site, and can be allowed for a particular macro by adding `#[allow(macro_trailing_semicolon)]`. The lint is set to warn for all internal rustc crates (when being built by a stage1 compiler). After the next beta bump, we can enable the lint for the bootstrap compiler as well.
…llaumeGomez,jyn514
rustdoc: Render HRTB correctly for bare functions
The angle brackets were not rendered, so code like this:
some_func: for<'a> fn(val: &'a i32) -> i32
would be rendered as:
some_func: fn'a(val: &'a i32) -> i32
However, rendering with angle brackets is still invalid syntax:
some_func: fn<'a>(val: &'a i32) -> i32
so now it renders correctly as:
some_func: for<'a> fn(val: &'a i32) -> i32
-----
However, note that this code:
some_trait: dyn for<'a> Trait<'a>
will still render as:
some_trait: dyn Trait<'a>
which is not invalid syntax, but is still unclear. Unfortunately I think
it's hard to fix that case because there isn't enough information in the
`rustdoc::clean::Type` that this code operates on. Perhaps that case can
be fixed in a later PR.
r? `@jyn514`
Use -target when linking binaries for Mac Catalyst When running `rustc` with `-target x86_64-apple-ios-macabi`, the linker eventually gets run with `-arch x86_64`, because the linker back end splits the LLVM target triple and uses the first token as the target architecture. However, this does not work for the Mac Catalyst ABI, which is a separate target from Darwin. Specifying the full target triple with `-target` allows Mac Catalyst binaries to link and run. closes rust-lang#80202
…=nikomatsakis Make hitting the recursion limit in projection non-fatal This change was originally made in rust-lang#80246 to avoid future (effectively) infinite loop bugs in projections, but wundergraph relies on rustc recovering here. cc rust-lang#80953 r? `@nikomatsakis`
…1011 Point to span of upvar making closure FnMut For rust-lang#80313.
Improve safety of `LateContext::qpath_res` This is my first rustc code change, inspired by hacking on clippy! The first change is to clear cached `TypeckResults` from `LateContext` when visiting a nested item. I took a hint from [here](https://github.com/rust-lang/rust/blob/5e91c4ecc09312d8b63d250a432b0f3ef83f1df7/compiler/rustc_privacy/src/lib.rs#L1300). Clippy has a `qpath_res` util function to avoid a possible ICE in `LateContext::qpath_res`. But the docs of `LateContext::qpath_res` promise no ICE. So this updates the `LateContext` method to keep its promises, and removes the util function. Related: rust-lang/rust-clippy#4545 CC ```````````@eddyb``````````` since you've done related work CC ```````````@flip1995``````````` FYI
…=Mark-Simulacrum BTreeMap: correct node size test case for choices of B r? ```@Mark-Simulacrum```
|
@bors r+ rollup=never p=5 |
|
📌 Commit 4e84bf5 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 4e84bf5 with merge fcf697f90206e9c87b39d494f94ab35d976bfc60... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
SEMICOLON_IN_EXPRESSIONS_FROM_MACROSlint #79819 (AddSEMICOLON_IN_EXPRESSIONS_FROM_MACROSlint)LateContext::qpath_res#81176 (Improve safety ofLateContext::qpath_res)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup