Rollup of 6 pull requests - #163033
Closed
jhpratt wants to merge 14 commits into
Closed
Rollup of 6 pull requests#163033jhpratt wants to merge 14 commits into
jhpratt wants to merge 14 commits into
Conversation
Some pauth tests have ended up failing since they were not run in CI. Make them run and make them pass.
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.
…r=Enselic tests: Run more pauth tests in CI and make them pass Some pauth tests have ended up failing since they were not run in CI. Make them run and make them pass. This is a follow up to: rust-lang#161183
post GH comment on types nominations This feature is cool, we want it for types nominations, as seen in https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/a.20.23zulip-stream.20topic.20was.20opened.20to.20discuss.20this.20issue r? @Mark-Simulacrum
…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>
…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.
…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
Member
Author
|
@bors r+ p=5 |
Contributor
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Sep 19, 2026
Rollup of 6 pull requests Successful merges: - #162228 (tests: Run more pauth tests in CI and make them pass) - #162990 (post GH comment on types nominations) - #162705 (Trigger "C array" parse error recovery in far fewer cases) - #162988 (recover `true` and `false` in type position as `bool`) - #163006 (Use `end_point` for trailing brace in `let...else` diagnostics) - #163007 (add Dir::try_clone)
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Contributor
|
💔 Test for 0dbb171 failed: CI. Failed job:
|
Contributor
|
PR #162228, which is a member of this rollup, was unapproved. |
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
9 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:
trueandfalsein type position asbool#162988 (recovertrueandfalsein type position asbool)end_pointfor trailing brace inlet...elsediagnostics #163006 (Useend_pointfor trailing brace inlet...elsediagnostics)r? @ghost
Create a similar rollup