Rollup of 13 pull requests - #163035
Closed
jhpratt wants to merge 49 commits into
Closed
Rollup of 13 pull requests#163035jhpratt wants to merge 49 commits into
jhpratt wants to merge 49 commits into
Conversation
rust-analyzer has a query for this, so we want to use it there. I don't know if using a query for this will be a perf win for rustc, but rust-analyzer already has this query for other reasons, so it feels a waste to not use it.
…or the long removed type ascription
…dead Remove incorrect parse error recovery code that mistakes `as` casts for the long removed type ascription Back when we still had type ascription syntax `$expr : $ty`, `parse_assoc_op_cast` would parse both `as` casts & type ascription. During that time (namely in commit rust-lang@8c5dafd), parse error recovery from code like `label: loop {}` was added (label lacks leading apostrophe). However, it never checked if we did actually parse a `:` and not an `as` meaning *to this day* we emit a nonsensical diagnostic for expressions like `label as loop {}`! This PR does away with this code & further cleans up in the area (thanks to type ascription being gone). In case you're wondering, we do still recover from expr *stmts* like `label: loop {}` as we have some code in the stmt parser for this. Since the removal of the type ascription syntax we do indeed no longer provide that recovery for arbitrary exprs (e.g, `(label: loop {})`) which I find absolutely acceptable. <sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
…nBrouwer
Trigger "C array" parse error recovery in far fewer cases
Previously we would trigger on
1. `unsafe { 1, 2, 3 }` and suggest `[ { 1, 2, 3 ]` (sic!)
2. `'label: { 1, 2, 3 }` and suggest `[: { 1, 2, 3 ]` (sic!)
3. `X::<{ 1, 2, 3 }>` and suggest `X::<[ 1, 2, 3]>` (wrong)
4. `|| -> i32 { 1, 2, 3 }` and suggest `|| -> i32 [ 1, 2, 3 ]` (wrong)
5. `await { 1, 2, 3 }` and suggest `await [ 1, 2, 3 ]` (wrong)
Moreover, stop looking for identifiers after the `{` as that case can no longer be reached anyway as `maybe_recover_bad_struct_literal_path` will always snatch it first.
I haven't added any regression tests as I don't think it'd be worth it / proportionate (it's a niche parse error recovery gone awry in very odd cases). Let me know if you think otherwise.
<sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
…they Add .seek_read_exact(), .seek_write_all() to std::os::windows::fs::FileExt Tracking issue: rust-lang#162868 This adds `.seek_read_exact()` to `std::os::windows::fs::FileExt`, an exact port of `read_exact_at()` for `std::os::unix::fs::FileExt`. And it adds `.seek_write_all()` to `std::os::windows::fs::FileExt`, an exact port of `write_all_at()` for `std::os::unix::fs::FileExt`. Finally, it adds six tests. First there is a smoke test for `seek_read_exact()`, `seek_write_all()`, an exact port of the test for the `.seek_read()`, `.seek_write()` methods. This is to make sure we are getting the same pass-through behavior through the lens of established tests. Then there are five tests for the `windows::fs::FileExt` trait itself, covering all `seek_read_exact()`, `seek_write_all()` corner cases except `io::ErrorKind::Interrupted` (advise welcome on that one). These tests use mock implementations of the traits `seek_read()` and `seek_write()` methods. No LLMs were used in writing this PR.
…chenyukang recover `true` and `false` in type position as `bool` Fixes rust-lang#162947 I asked for a bit of help in [#t-compiler/help > parser help with issue 162947](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/parser.20help.20with.20issue.20162947/with/625278094) and was advised to this solution. This doesn't help if another keyword instead of `true` or `false` is used in type position, but i assume this is rare (don't think it has ever happened to me). I also think this could lead to confusing error messages if the user has a type called `True` or `False`. When this then is typoed as lowercase it would be made to a bool. I assume this is also rare. No AI used.
…, r=jhpratt Constify `impl FromStr for NonZero<T>` `<integer>::from_str` has been `const`. `NonZero::from_str` can also be `const`. rust-lang#143773
…e, r=folkertdev
Use `end_point` for trailing brace in `let...else` diagnostics
The following ICEs because `｝` is a fullwidth lookalike of `}`:
```rs
fn main() {
let x = {1｝ else { return; };
}
```
The diagnostic for a trailing curly brace before else in a let...else statement computed the brace span with `span.hi() - BytePos(1)`. That assumes the brace is a single ASCII byte.
add Dir::try_clone There's no `try_clone` listed on rust-lang#120426 but I assume that's a standard operation for all kinds of file descriptors? Cc @the8472 @ChrisDenton
rustbot
added
A-meta
Member
Author
|
@bors r+ p=5 |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 19, 2026
Rollup of 13 pull requests Successful merges: - #158515 (Make let-else respect macro_rules expr metavariable grouping) - #160097 (fix const_item_mutation lint to use needs_drop instead of has_dtor) - #161435 (Provide a `supertrait_def_ids()` function in rustc_type_ir's interner) - #161894 (Do not suppress the fn item uniqueness note for late bound lifetimes) - #162990 (post GH comment on types nominations) - #154665 (add safety section for mem::zeroed) - #162700 ( Remove incorrect parse error recovery code that mistakes `as` casts for the long removed type ascription) - #162705 (Trigger "C array" parse error recovery in far fewer cases) - #162875 (Add .seek_read_exact(), .seek_write_all() to std::os::windows::fs::FileExt) - #162988 (recover `true` and `false` in type position as `bool`) - #162995 (Constify `impl FromStr for NonZero<T>`) - #163006 (Use `end_point` for trailing brace in `let...else` diagnostics) - #163007 (add Dir::try_clone)
This comment has been minimized.
This comment has been minimized.
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-review
Contributor
|
💔 Test for f48a369 failed: CI. Failed job:
|
Member
|
Spurious |
rust-bors
Bot
added
the
S-waiting-on-author
rustbot
removed
the
S-waiting-on-review
Contributor
|
This pull request was unapproved due to being closed. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
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:
supertrait_def_ids()function in rustc_type_ir's interner #161435 (Provide asupertrait_def_ids()function in rustc_type_ir's interner)ascasts for the long removed type ascription #162700 ( Remove incorrect parse error recovery code that mistakesascasts for the long removed type ascription)trueandfalsein type position asbool#162988 (recovertrueandfalsein type position asbool)impl FromStr for NonZero<T>#162995 (Constifyimpl FromStr for NonZero<T>)end_pointfor trailing brace inlet...elsediagnostics #163006 (Useend_pointfor trailing brace inlet...elsediagnostics)r? @ghost
Create a similar rollup