Tweak handling of "struct like start" where a struct isn't supported by estebank · Pull Request #147004 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation5 Commits2 Checks10 Files changed
Conversation
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
[ Show hidden characters]({{ revealButtonHref }})
This improves the case where someone tries to write a match expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like match a { b: would confuse the parser and think everything after match must be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
This improves the case where someone tries to write a match expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfuly parsed as such.
Status: Awaiting review from the assignee but also interested parties.
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
r? @fee1-dead
rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.
Use r? to explicitly pick a reviewer
This comment has been minimized.
This comment has been minimized.
📌 Commit bb48c16 has been approved by fee1-dead
It is now in the queue for this repository.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Zalathar added a commit to Zalathar/rust that referenced this pull request
…-dead
Tweak handling of "struct like start" where a struct isn't supported
This improves the case where someone tries to write a match expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like match a { b: would confuse the parser and think everything after match must be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
bors added a commit that referenced this pull request
Rollup of 10 pull requests
Successful merges:
- #146281 (Support
#[rustc_align_static]insidethread_local!) - #146535 (mbe: Implement
unsafeattribute rules) - #146585 (indexing: reword help)
- #147004 (Tweak handling of "struct like start" where a struct isn't supported)
- #147221 (Forbid
//@ compile-flags: -Cincremental=in tests) - #147225 (Don't enable shared memory by default with Wasm atomics)
- #147227 (implement
Box::take) - #147231 (Extending
#[rustc_force_inline]to be applicable to inherent methods) - #147233 (Initialize llvm submodule if not already the case to run citool)
- #147236 (Update books)
r? @ghost
@rustbot modify labels: rollup
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…-dead
Tweak handling of "struct like start" where a struct isn't supported
This improves the case where someone tries to write a match expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like match a { b: would confuse the parser and think everything after match must be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
jhpratt added a commit to jhpratt/rust that referenced this pull request
…-dead
Tweak handling of "struct like start" where a struct isn't supported
This improves the case where someone tries to write a match expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like match a { b: would confuse the parser and think everything after match must be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
bors added a commit that referenced this pull request
Rollup of 9 pull requests
Successful merges:
- #146281 (Support
#[rustc_align_static]insidethread_local!) - #146535 (mbe: Implement
unsafeattribute rules) - #146585 (indexing: reword help)
- #147004 (Tweak handling of "struct like start" where a struct isn't supported)
- #147221 (Forbid
//@ compile-flags: -Cincremental=in tests) - #147225 (Don't enable shared memory by default with Wasm atomics)
- #147227 (implement
Box::take) - #147233 (Initialize llvm submodule if not already the case to run citool)
- #147236 (Update books)
r? @ghost
@rustbot modify labels: rollup
rust-timer added a commit that referenced this pull request
Rollup merge of #147004 - estebank:ascription-in-pat, r=fee1-dead
Tweak handling of "struct like start" where a struct isn't supported
This improves the case where someone tries to write a match expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like match a { b: would confuse the parser and think everything after match must be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request
rust-cloud-vms bot pushed a commit to makai410/rustc_public that referenced this pull request
flip1995 pushed a commit to flip1995/rust-clippy that referenced this pull request
makai410 pushed a commit to makai410/rust that referenced this pull request
…-dead
Tweak handling of "struct like start" where a struct isn't supported
This improves the case where someone tries to write a match expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like match a { b: would confuse the parser and think everything after match must be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
makai410 pushed a commit to makai410/rust that referenced this pull request
makai410 pushed a commit to makai410/rust that referenced this pull request
…-dead
Tweak handling of "struct like start" where a struct isn't supported
This improves the case where someone tries to write a match expr where the patterns have type ascription syntax. Makes them less verbose, by giving up on the first encounter in the block, and makes them more accurate by only treating them as a struct literal if successfully parsed as such.
Before, encountering something like match a { b: would confuse the parser and think everything after match must be a struct, and if it wasn't it would generate a cascade of unnecessary diagnostics.
makai410 pushed a commit to makai410/rust that referenced this pull request
makai410 pushed a commit to makai410/rustc_public that referenced this pull request
Labels
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the compiler team, which will review and decide on the PR/issue.