-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 9 pull requests #137283
Closed
Closed
Rollup of 9 pull requests #137283
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
Using if ... with the intent to avoid branches can be surprising to readers and carries the risk of turning into jumps/branches generated by some future compiler version, breaking crucial optimizations. This commit replaces their usage with the explicit and IR annotated `bool::select_unpredictable`.
The `#[must_use]` attribute has no effect when applied to methods in trait implementations.
The `#[must_use]` attribute has no effect when applied to methods in trait implementations.
* Order items as the average of the two adaptors. Enables easier diffs. * Consistently apply #[inline]. * Implement FromInner<Vec<u8>> for bytes::Buf. * Implement Clone::clone_from for wtf8::Buf.
When `Foo.field` or `Foo.method()` exprs are encountered, suggest `Foo::field` or `Foo::method()` when Foo is a type alias, not just a struct, trait, or module. Also rename test for this suggestion from issue-22692.rs to something more meaningful.
Suggest replacing `.` with `::` when encountering "expected value, found enum": - in a method-call expression and the method has the same name as a tuple variant - in a field-access expression and the field has the same name as a unit or tuple variant
…cro giving a type, make it also work when the rhs is a type alias, not just a struct.
The `#[must_use]` attribute has no effect when applied to methods in trait implementations. This case was not linted before.
This also adds `#[cfg]` attributes to tests for bindings' types, to make it visually clearer which revisions type successfully.
These are superseded by the old-edition revisions on the shared tests.
My reasoning: the ruleset implemented by the same feature gate in Edition 2024 always tries to eat the inherited reference first. For consistency, it makes sense to me to say across all editions that users should consider the inherited reference's mutability when wondering if a `&mut` pattern will type.
Co-authored-by: Nadrieril <[email protected]>
also move the existing tests to a more sensible location
…45795, r=m-ou-se Add `MAX_LEN_UTF8` and `MAX_LEN_UTF16` Constants This pull request adds the `MAX_LEN_UTF8` and `MAX_LEN_UTF16` constants as per rust-lang#45795, gated behind the `char_max_len` feature. The constants are currently applied in the `alloc`, `core` and `std` libraries.
…nieu Impl TryFrom<Vec<u8>> for String I think this is useful enough to have :) As a general question, is there any policy around adding "missing" trait implementations? (like adding `AsRef<T> for T` for std types), I mostly stumble upon them when using a lot of "impl Trait in argument position" like (`foo: impl Into<String>`)
…, r=Nadrieril Match Ergonomics 2024: update old-edition behavior of feature gates This updates the behavior of the feature gates `ref_pat_eat_one_layer_2024_structural` and `ref_pat_eat_one_layer_2024` in Editions 2021 and earlier to correspond to the left and right typing rules compared [here](https://nadrieril.github.io/typing-rust-patterns/?opts1=AQEBAQIBAQEBAAAAAAAAAAAAAAAAAAA%3D&style=UserVisible&compare=true&opts2=AQEBAQIBAQABAAAAAQEBAAEBAAABAAA%3D&mode=rules), respectively. Compared to the `stable_rust` rules: - they both allow reference patterns to match a lone inherited ref, - they both allow `&` patterns to eat `&mut` reference types (and lone `&mut` inherited refs) as if they're shared, - they both allow `&mut` patterns to eat `&` reference types when there's a `&mut` inherited reference to also eat, - and the left ruleset has RFC 3627's Rule 3: after encountering a shared reference type in the scrutinee, the default binding mode will be treated as by-shared-ref when it would otherwise be by-mutable-ref. I think there's already tests for all of those typing rules, so I've added revisions to use the existing tests with the new rulesets. Additionally, I've added a few tests to make sure we handle mixed-edition patterns appropriately, and I've added references to the unstable book. Relevant tracking issue: rust-lang#123076 r? `@ghost`
…_3, r=davidtwco Suggest replacing `.` with `::` in more error diagnostics. First commit makes the existing "help: use the path separator to refer to an item" also work when the base is a type alias, not just a trait/module/struct. The existing unconditional `DefKind::Mod | DefKind::Trait` match arm is changed to a conditional `DefKind::Mod | DefKind::Trait | DefKind::TyAlias` arm that only matches if the `path_sep` suggestion-adding closure succeeds, so as not to stop the later `DefKind::TyAlias`-specific suggestions if the path-sep suggestion does not apply. This shouldn't change behavior for `Mod` or `Trait` (due to the default arm's `return false` etc). This commit also updates `tests/ui/resolve/issue-22692.rs` to reflect this, and also renames it to something more meaningful. This commit also makes the `bad_struct_syntax_suggestion` closure take `err` as a parameter instead of capturing it, since otherwise caused borrowing errors due to the change to using `path_sep` in a pattern guard. <details> <summary> Type alias diagnostic example </summary> ```rust type S = String; fn main() { let _ = S.new; } ``` ```diff error[E0423]: expected value, found type alias `S` --> diag7.rs:4:13 | 4 | let _ = S.new; | ^ | - = note: can't use a type alias as a constructor + help: use the path separator to refer to an item + | +4 | let _ = S::new; + | ~~ ``` </details> Second commit adds some cases for `enum`s, where if there is a field/method expression where the field/method has the name of a unit/tuple variant, we assume the user intended to create that variant[^1] and suggest replacing the `.` from the field/method suggestion with a `::` path separator. If no such variant is found (or if the error is not a field/method expression), we give the existing suggestion that suggests adding `::TupleVariant(/* fields */)` after the enum. <details> <summary> Enum diagnostic example </summary> ```rust enum Foo { A(u32), B, C { x: u32 }, } fn main() { let _ = Foo.A(42); // changed let _ = Foo.B; // changed let _ = Foo.D(42); // no change let _ = Foo.D; // no change let _ = Foo(42); // no change } ``` ```diff error[E0423]: expected value, found enum `Foo` --> diag8.rs:8:13 | 8 | let _ = Foo.A(42); // changed | ^^^ | note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ -help: you might have meant to use the following enum variant - | -8 | let _ = Foo::B.A(42); // changed - | ~~~~~~ -help: alternatively, the following enum variant is available +help: use the path separator to refer to a variant | -8 | let _ = (Foo::A(/* fields */)).A(42); // changed - | ~~~~~~~~~~~~~~~~~~~~~~ +8 | let _ = Foo::A(42); // changed + | ~~ error[E0423]: expected value, found enum `Foo` --> diag8.rs:9:13 | 9 | let _ = Foo.B; // changed | ^^^ | note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ -help: you might have meant to use the following enum variant - | -9 | let _ = Foo::B.B; // changed - | ~~~~~~ -help: alternatively, the following enum variant is available +help: use the path separator to refer to a variant | -9 | let _ = (Foo::A(/* fields */)).B; // changed - | ~~~~~~~~~~~~~~~~~~~~~~ +9 | let _ = Foo::B; // changed + | ~~ error[E0423]: expected value, found enum `Foo` --> diag8.rs:10:13 | 10 | let _ = Foo.D(42); // no change | ^^^ | note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ help: you might have meant to use the following enum variant | 10 | let _ = Foo::B.D(42); // no change | ~~~~~~ help: alternatively, the following enum variant is available | 10 | let _ = (Foo::A(/* fields */)).D(42); // no change | ~~~~~~~~~~~~~~~~~~~~~~ error[E0423]: expected value, found enum `Foo` --> diag8.rs:11:13 | 11 | let _ = Foo.D; // no change | ^^^ | note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ help: you might have meant to use the following enum variant | 11 | let _ = Foo::B.D; // no change | ~~~~~~ help: alternatively, the following enum variant is available | 11 | let _ = (Foo::A(/* fields */)).D; // no change | ~~~~~~~~~~~~~~~~~~~~~~ error[E0423]: expected function, tuple struct or tuple variant, found enum `Foo` --> diag8.rs:12:13 | 12 | let _ = Foo(42); // no change | ^^^ help: try to construct one of the enum's variants: `Foo::A` | = help: you might have meant to construct the enum's non-tuple variant note: the enum is defined here --> diag8.rs:1:1 | 1 | / enum Foo { 2 | | A(u32), 3 | | B, 4 | | C { x: u32 }, 5 | | } | |_^ error: aborting due to 5 previous errors ``` </details> [^1]: or if it's a field expression and a tuple variant, that they meant to refer the variant constructor.
…eliable-ptr-select, r=thomcc Use more explicit and reliable ptr select in sort impls Using `if ...` with the intent to avoid branches can be surprising to readers and carries the risk of turning into jumps/branches generated by some future compiler version, breaking crucial optimizations. This commit replaces their usage with the explicit and IR annotated `bool::select_unpredictable`.
CI: Stop /msys64/bin from being prepended to PATH in msys2 shell We used to do this along time ago but we stopped doing it when we started installing msys2 manually. https://github.com/rust-lang/rust/blob/4fd3cf96a1db7771ef4f332b9eb1ad17fa0fd091/src/ci/scripts/install-msys2.sh#L11-L13 Fixes rust-lang#136795 try-job: dist-i686-mingw
…=davidtwco Lint `#[must_use]` attributes applied to methods in trait impls The `#[must_use]` attribute has no effect when applied to methods in trait implementations. This PR adds it to the unused `#[must_use]` lint, and cleans the extra attributes in portable-simd and Clippy.
…Denton Organize `OsString`/`OsStr` shims Synchronize the `bytes.rs` and `wtf8.rs` shims for `OsString`/`OsStr` so they're easier to diff between each other. This is mostly ordering items the same between the two. I tried to minimize moves and went for the average locations between the files. With them in the same order, it is clear that `FromInner<_>` is not implemented for `bytes::Buf` and `Clone::clone_from` is not implemented for `wtf8::Buf`, but they are for the other. Fix that. I added #[inline] to all inherent methods of the `OsString`/`OsStr` shims, because it seemed that was already the rough pattern. `bytes.rs` has more inlining than `wtf8.rs`, so I added the corresponding ones to `wtf8.rs`. Then, the common missing ones have no discernible pattern to me. They're not divided by non-allocating/allocating. Perhaps the pattern is that UTF-8 validation isn't inlined? Since these types are merely the inner values in `OsStr`/`OsString`, I put inline on all methods and let those public types dictate inlining. I have not inspected codegen or run benchmarks. Also, touch up some (private) documentation comments. r? `````@ChrisDenton`````
vectorcall ABI: require SSE2 According to the official docs at https://learn.microsoft.com/en-us/cpp/cpp/vectorcall, SSE2 is required for this ABI. Add a check that enforces this. I put this together with the other checks ensuring the target features required for a function are present... however, since the ABI is known pre-monomorphization, it would be possible to do this check earlier, which would have the advantage of checking even in `cargo check`. It would have the disadvantage of spreading this code in yet more places. The first commit just does a little refactoring of the mono-time ABI check to make it easier to add the new check. Cc `@workingjubilee`
@bors r+ rollup=never p=5 |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 19, 2025
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#120580 (Add `MAX_LEN_UTF8` and `MAX_LEN_UTF16` Constants) - rust-lang#132268 (Impl TryFrom<Vec<u8>> for String) - rust-lang#136093 (Match Ergonomics 2024: update old-edition behavior of feature gates) - rust-lang#136344 (Suggest replacing `.` with `::` in more error diagnostics.) - rust-lang#136690 (Use more explicit and reliable ptr select in sort impls) - rust-lang#136815 (CI: Stop /msys64/bin from being prepended to PATH in msys2 shell) - rust-lang#136923 (Lint `#[must_use]` attributes applied to methods in trait impls) - rust-lang#137155 (Organize `OsString`/`OsStr` shims) - rust-lang#137225 (vectorcall ABI: require SSE2) Failed merges: - rust-lang#136780 (std: move stdio to `sys`) 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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-attributes
Area: Attributes (`#[…]`, `#![…]`)
A-testsuite
Area: The testsuite used to check the correctness of rustc
A-tidy
Area: The tidy tool
O-windows
Operating system: Windows
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-infra
Relevant to the infrastructure team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
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:
MAX_LEN_UTF8
andMAX_LEN_UTF16
Constants #120580 (AddMAX_LEN_UTF8
andMAX_LEN_UTF16
Constants).
with::
in more error diagnostics. #136344 (Suggest replacing.
with::
in more error diagnostics.)#[must_use]
attributes applied to methods in trait impls #136923 (Lint#[must_use]
attributes applied to methods in trait impls)OsString
/OsStr
shims #137155 (OrganizeOsString
/OsStr
shims)Failed merges:
sys
#136780 (std: move stdio tosys
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup