Rollup of 5 pull requests #135755
Merged
Rollup of 5 pull requests #135755
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 aims to reduce the complexity needed in the boolean logic for telling which rules we're using to type patterns. If we still want the functionality this removes, we can re-add it later, after some cleanup to pattern typing.
As far as I can tell, the assignment removed here will never do anything. `pat_info.max_ref_mutbl` starts at `MutblCap::Mut` for the top-level pattern and is only changed if feature gates are enabled that would result in the statement not being executed. Regardless of what new pattern typing rules are adopted, I don't imagine we want to conditionally reset `max_ref_mutbl` based on edition either, since it'd have consequences for subpatterns in other editions.
If Rules 3 or 5 are adopted in any edition, we'll need to track the `MutblCap` in all editions for macro hygiene purposes. Previously, the check for whether to track it was conflated with the checks for whether to apply Rules 3 and 5, so to make it a bit clearer, this always tracks the `MutblCap`. If needed, we could check if Rules 3 or 5 are present in any edition before tracking the `MutblCap`, but since it's not that much more expensive to always track it, I've figured that's simplest. My main concern with removing the checks is that it may not be clear that the `MutblCap` is tracked for those specific purposes. To try and mitigate this, I've made its doc comment a bit more precise regarding the extent of how and why it's used. This leaves the condition untouched on the `cap_to_weakly_not` call needed for Rule 5, since it's only needed for that and it can affect diagnostics.
The goal of this cleanup is to make it more apparent which feature gates correspond to which typing rules, and which typing rules correspond to what code. My intent is for calls to the "which typing rules do we have?" functions to be replaced by comments (and edition checks, as appropriate), but as long as we're experimenting with multiple rulesets, this seemed to me to be the easiest to document and read. There's still some nontrivial control flow, but I've added comments to try and make it clearer. There's some logic that looks like it could be de-duplicated across different ways of matching against inherited references; however, the duplication is intentional. Once we choose which rulesets we want, we can make this more clever, but until then, my priorities are clarity and ease of modification/extension. That said, I think the diagnostics could use some work; factoring out commonalities there (and separating them from the typing logic) would be ideal. I've opted not to include that here both since it'd make this refactor less obvious and since it affects test output. Also, this doesn't get quite as fine-grained as Typing Rust Patterns, so there's some instances where certain rules are conflated. I'd prefer to minimize dead/untested codepaths for rulesets we're not interested in, so as a compromise I've added comments wherever some aspect of the typing rules is assumed from another. I'm not totally happy with it, but I think it's at least better than plain checks against the feature gates and edition.
This only includes previously existing tests (with a couple duplicates removed). I plan on adding more comprarisons where the rules differ once I've updated the pattern typing rules. I also haven't touched the tests for new rules in old editions; I'll see how best to handle that once those rules are updated as well.
Creating a "trimmed DefID path" when no error is being emitted is an ICE (on purpose). If we create a trimmed path for a lint that is then silenced before being emitted causes a known ICE. This side-steps the issue by always using `with_no_trimmed_path!`. This was verified to fix /~https://github.com/quinn-rs/quinn/, but couldn't write a repro case for the test suite. Fix rust-lang#135289.
This also makes it test the "structural" ruleset, in preparation for additional tests where the rulesets disagree.
This was a test for `ref_pat_eat_one_layer_2024` downgrading a `mut ref` default binding mode to `ref` within a shared reference pattern (i.e. Rule 3) on edition 2021 specifically. Since it's near-identical to another existing test (currently in `ref_pat_eat_one_layer_2021.rs` in the "experimental" rfc 3627 subdirectory) and that particular feature gate's typing rulesets are planned to no longer have Rule 3, I'm opting to remove it rather than continue maintaining it separately.
This adds explanation of inherited references and how they relate to the default binding mode. Co-authored-by: Nadrieril <Nadrieril@users.noreply.github.com>
…attr, r=SparrowLii fully de-stabilize all custom inner attributes `#![test]` and `#![rustfmt::skip]` were accidentally accepted in more places than they should. These have been marked as soft-unstable since forever (rust-lang#82399) and shown in future-compat reports since Rust 1.77 (rust-lang#116274). Cc `@rust-lang/lang` `@petrochenkov`
…eril Match Ergonomics 2024: document and reorganize the currently-implemented feature gates The hope here is to make it easier to adjust, understand, and test the experimental pattern typing rules implemented in the compiler. This PR doesn't (or at isn't intended to) change any behavior or add any new tests; I'll be handling that later. I've also included some reasoning/commentary on the more involved changes in the commit messages. Relevant tracking issue: rust-lang#123076 r? `@Nadrieril`
Always force non-trimming of path in `unreachable_patterns` lint Creating a "trimmed DefID path" when no error is being emitted is an ICE (on purpose). If we create a trimmed path for a lint that is then silenced before being emitted causes a known ICE. This side-steps the issue by always using `with_no_trimmed_path!`. This was verified to fix /~https://github.com/quinn-rs/quinn/, but couldn't write a repro case for the test suite. Fix rust-lang#135289.
…r=Mark-Simulacrum
further improve panic_immediate_abort by removing rtprintpanic! messages
Reduces binary size using `panic_immediate_abort` by removing strings used by `rtprintpanic!`.
for `main.rs`
```rust
fn main() {
println!("Hello, world!");
}
```
with `Cargo.toml`
```toml
[package]
name = "tst"
version = "0.1.0"
edition = "2024"
[dependencies]
[profile.release]
lto = true
codegen-units = 1
panic = "abort"
```
and build with `RUSTFLAGS="-Zlocation-detail=none -Zfmt-debug=none" cargo +stage-1 b -r -Z build-std=std,panic_abort -Z build-std-features=optimize_for_size,panic_immediate_abort` for `x86_64-unknown-linux-gnu`
This reduces size:
| before | after | type |
| - | - | - |
| 25256 | 21880 | unstripped |
| 18072 | 15288 | stripped |
…_through_unstable_modules, r=Mark-Simulacrum Remove dead rustc_allowed_through_unstable_modules for std::os::fd contents As far as I was able to reconstruct, the history here is roughly as follows: - rust-lang#99723 added some `rustc_allowed_through_unstable_modules` to the types in `std::os::fd::raw` since they were accessible on stable via the unstable `std::os::wasi::io::AsRawFd` path. (This was needed to fix rust-lang#99502.) - Shortly thereafter, rust-lang#98368 re-organized things so that instead of re-exporting from an internal `std::os::wasi::io::raw`, `std::os::wasi::io::AsRawFd` is now directly re-exported from `std::os::fd`. This also made `library/std/src/os/wasi/io/raw.rs` entirely dead code as far as I can tell, it's not imported by anything any more. - Shortly thereafter, rust-lang#103308 stabilizes `std::os::wasi::io`, so `rustc_allowed_through_unstable_modules` is not needed any more to access `std::os::wasi::io::AsRawFd`. There is even a comment in `library/std/src/os/wasi/io/raw.rs` saying the attribute can be removed now, but that file is dead code so it is not touched as part of the stabilization. I did a grep for `pub use crate::os::fd` and all the re-exports I could find are in stable modules. So given all that, we can remove the `rustc_allowed_through_unstable_modules` (hoping they are not also re-exported somewhere else, it's really hard to be sure about this). I have checked that std still builds after this PR on the wasm32-wasip2 target.
rustbot
added
O-wasi
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 9a1d156f38 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jan 20, 2025
|
Finished benchmarking commit (ecda83b): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (secondary -3.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: 766.411s -> 765.63s (-0.10%) |
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:
unreachable_patternslint #135310 (Always force non-trimming of path inunreachable_patternslint)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup