Rollup of 9 pull requests #129936
Merged
Rollup of 9 pull requests #129936
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
Inspired by discussion on rust-lang#129486 this is intended to at least document the current state of the world in a more public location than throughout a series of issues.
The actual implementation remains in `rustc_mir_dataflow`, but this commit moves the `MirPass` impl to `rustc_mir_transform` and changes it to a `MirLint` (fixing a `FIXME` comment). (I originally tried moving the full implementation from `rustc_mir_dataflow` but I had some trait problems with `HasMoveData` and `RustcPeekAt` and `MaybeLiveLocals`. This commit was much smaller and simpler, but still will allow some follow-up cleanups.)
Because that's now the only crate that uses it. Moving stuff out of `rustc_middle` is always welcome. I chose to use `impl crate::MirPass`/`impl crate::MirLint` (with explicit `crate::`) everywhere because that's the only mention of `MirPass`/`MirLint` used in all of these files. (Prior to this change, `MirPass` was mostly imported via `use rustc_middle::mir::*` items.)
They're now all just used within this crate.
Forgot this during the release process
…stebank Suggest `impl Trait` for References to Bare Trait in Function Header Fixes rust-lang#125139 This PR suggests `impl Trait` when `&Trait` is found as a function parameter type or return type. This makes use of existing diagnostics by adding `peel_refs()` when checking for type equality. Additionaly, it makes a few other improvements: 1. Checks if functions inside impl blocks have bare trait in their headers. 2. Introduces a trait `NextLifetimeParamName` similar to the existing `NextTypeParamName` for suggesting a lifetime name. Also, abstracts out the common logic between the two trait impls. ### Related Issues I ran into a bunch of related diagnostic issues but couldn't fix them within the scope of this PR. So, I have created the following issues: 1. [Misleading Suggestion when Returning a Reference to a Bare Trait from a Function](rust-lang#127689) 2. [Verbose Error When a Function Takes a Bare Trait as Parameter](rust-lang#127690) 3. [Incorrect Suggestion when Returning a Bare Trait from a Function](rust-lang#127691) r? ```@estebank``` since you implemented rust-lang#119148
…bank Don't Suggest Labeling `const` and `unsafe` Blocks Fixes rust-lang#128604 Previously, both anonymous constant blocks (E.g. The labeled block inside `['_'; 'block: { break 'block 1 + 2; }]`) and inline const blocks (E.g. `const { ... }`) were considered to be the same kind of blocks. This caused the compiler to incorrectly suggest labeling both the blocks when only anonymous constant blocks can be labeled. This PR adds an other enum variant to `Context` so that both the blocks can be handled appropriately. Also, adds some doc comments and removes unnecessary `&mut` in a couple of places.
…, r=compiler-errors Non-exhaustive structs may be empty This is a follow-up to a discrepancy noticed in rust-lang#122792: today, the following struct is considered inhabited (non-empty) outside its defining crate: ```rust #[non_exhaustive] pub struct UninhabitedStruct { pub never: !, // other fields } ``` `#[non_exhaustive]` on a struct should mean that adding fields to it isn't a breaking change. There is no way that adding fields to this struct could make it non-empty since the `never` field must stay and is inconstructible. I suspect this was implemented this way due to confusion with `#[non_exhaustive]` enums, which indeed should be considered non-empty outside their defining crate. I propose that we consider such a struct uninhabited (empty), just like it would be without the `#[non_exhaustive]` annotation. Code that doesn't pass today and will pass after this: ```rust // In a different crate fn empty_match_on_empty_struct<T>(x: UninhabitedStruct) -> T { match x {} } ``` This is not a breaking change. r? ``@compiler-errors``
…-on-wasm32-u-u, r=workingjubilee Document the broken C ABI of `wasm32-unknown-unknown` Inspired by discussion on rust-lang#129486 this is intended to at least document the current state of the world in a more public location than throughout a series of issues.
…esleywiser update comment regarding TargetOptions.features The claim that `-Ctarget-features` cannot disable these features set in the target spec is definitely wrong -- I tried it for `x86_64-pc-windows-gnu`, which enables SSE3 that way. Building with `-Ctarget-feature=-sse3` works fine, and `cfg!(target_feature = "sse3")` is `false` in that build. There are also some indications that these are actually intended to be overwritten: https://github.com/rust-lang/rust/blob/3b14526cead4105f82c398d8d4c7954efa3bab6b/compiler/rustc_target/src/spec/targets/i686_unknown_uefi.rs#L22-L23 https://github.com/rust-lang/rust/blob/84ac80f1921afc243d71fd0caaa4f2838c294102/compiler/rustc_target/src/spec/targets/x86_64h_apple_darwin.rs#L18-L23 So... let's update the comment to match reality, I guess? The claim that they overwrite `-Ctarget-cpu` is based on - for `native`, the comment in the apple target spec quoted above - for other CPU strings, the assumption that `LLVMRustCreateTargetMachine` will apply these features after doing whatever the base CPU model does. I am not sure how to check that, I hope some LLVM backend people can chime in. :)
do not attempt to prove unknowable goals In case a goal is unknowable, we previously still checked all other possible ways to prove this goal, even though its final result is already guaranteed to be ambiguous. By ignoring all other candidates in that case we can avoid a lot of unnecessary work, fixing the performance regression in typenum found in rust-lang#121848. This is already the behavior in the old solver. This could in theory cause future-compatability issues as considering fewer goals unknowable may end up causing performance regressions/hangs. I am quite confident that this will not be an issue. r? ``@compiler-errors``
…Pass, r=cjgillot Move `SanityCheck` and `MirPass` They are currently in `rustc_middle`. This PR moves them to `rustc_mir_transform`, which makes more sense. r? ``@cjgillot``
…tic, r=compiler-errors rustc_driver_impl: remove some old dead logic This got added in rust-lang@5013952, before `cfg(target_feature)` was stable. It should not be needed any more ever since `cfg(target_feature)` is stable.
…roalbini include 1.80.1 release notes on master Forgot this during the release process.
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=9 |
|
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
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 4, 2024
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#127692 (Suggest `impl Trait` for References to Bare Trait in Function Header) - rust-lang#128701 (Don't Suggest Labeling `const` and `unsafe` Blocks ) - rust-lang#128934 (Non-exhaustive structs may be empty) - rust-lang#129630 (Document the broken C ABI of `wasm32-unknown-unknown`) - rust-lang#129863 (update comment regarding TargetOptions.features) - rust-lang#129896 (do not attempt to prove unknowable goals) - rust-lang#129926 (Move `SanityCheck` and `MirPass`) - rust-lang#129928 (rustc_driver_impl: remove some old dead logic) - rust-lang#129930 (include 1.80.1 release notes on master) r? `@ghost` `@rustbot` modify labels: rollup
|
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
bors
added
S-waiting-on-bors
|
6 in a row 🙃 |
|
how high can we go? what's the best streak so far? 😆 |
|
I thought I was lucky when I got three in a row last week, Matthias blew my record out of the water here 😆 |
|
|
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 4ac7bcbaad In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Sep 5, 2024
|
Finished benchmarking commit (009e738): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -1.7%, secondary 0.5%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 751.188s -> 752.275s (0.14%) |
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:
impl Traitfor References to Bare Trait in Function Header #127692 (Suggestimpl Traitfor References to Bare Trait in Function Header)constandunsafeBlocks #128701 (Don't Suggest LabelingconstandunsafeBlocks )wasm32-unknown-unknown#129630 (Document the broken C ABI ofwasm32-unknown-unknown)SanityCheckandMirPass#129926 (MoveSanityCheckandMirPass)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup