Fix issue for module name when surround the struct literal with parentheses #112475

chenyukang · 2023-06-09T22:25:27Z

rustbot · 2023-06-09T22:25:32Z

(rustbot has picked a reviewer for you, use r? to override)

chenyukang · 2023-06-09T22:27:19Z

compiler/rustc_parse/src/parser/diagnostics.rs

+                        // `foo::Bar { ... } `
+                        // we expect to suggest `(foo::Bar { ... })` instead of `foo::(Bar { ... })`
+                        let sm = self.sess.source_map();
+                        let before = maybe_struct_name.span.shrink_to_lo();


It's not a great way, but in the parsing phase, we don't have more context here?
any better solution?

we don't have more context here?

Probably not.... We'd need to pass in more span information here, which it seems like we don't have.

It seems we need to get the spans of several previous tokens here, since the module path may contain multiple tokens, while parser keep prev_token and token.

I think this approach is ok

…arentheses

compiler/rustc_parse/src/parser/diagnostics.rs

compiler-errors · 2023-06-10T21:03:31Z

@bors r+

bors · 2023-06-10T21:03:33Z

📌 Commit f54e757 has been approved by compiler-errors

It is now in the queue for this repository.

…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#112475 (Fix issue for module name when surround the struct literal with parentheses) - rust-lang#112477 (Give more helpful progress messages in `Assemble`) - rust-lang#112484 (Fix ntdll linkage issues on Windows UWP platforms) - rust-lang#112492 (Migrate GUI colors test to original CSS color format) - rust-lang#112493 (iat selection: normalize self ty & completely erase bound vars) - rust-lang#112497 (abs_sub: fix typo 0[-:][+.]0) - rust-lang#112498 (Update links to Rust Reference in diagnostic) r? `@ghost` `@rustbot` modify labels: rollup

…scr, r=compiler-errors Mostly parser: Eliminate code that's been dead / semi-dead since the removal of type ascription syntax **Disclaimer**: This PR is intended to mostly clean up code as opposed to bringing about behavioral changes. Therefore it doesn't aim to address any of the 'FIXME: remove after a month [dated: 2023-05-02]: "type ascription syntax has been removed, see issue [#]101728"'. --- By commit: 1. Removes truly dead code: * Since 1.71 (rust-lang#109128) `let _ = { f: x };` is a syntax error as opposed to a semantic error which allows the parse-time diagnostic (suggestion) "*struct literal body without path // you might have forgotten […]*" to kick in. * The analysis-time diagnostic (suggestion) from <=1.70 "*cannot find value \`f\` in this scope // you might have forgotten […]*" is therefore no longer reachable. 2. Updates `is_certainly_not_a_block` to be in line with the current grammar: * The seq. `{ ident:` is definitely not the start of a block. Before the removal of ty ascr, `{ ident: ty_start` would begin a block expr. * This shouldn't make more code compile IINM, it should *ultimately* only affect diagnostics. * For example, `if T { f: () } {}` will now be interpreted as an `if` with struct lit `T { f: () }` as its *condition* (which is banned in the parser anyway) as opposed to just `T` (with the *consequent* being `f : ()` which is also invalid (since 1.71)). The diagnostics are almost the same because we have two separate parse recovery procedures + diagnostics: `StructLiteralNeedingParens` (*invalid struct lit*) before and `StructLiteralNotAllowedHere` (*struct lits aren't allowed here*) now, as you can see from the diff. * (As an aside, even before this PR, fn `maybe_suggest_struct_literal` should've just used the much older & clearer `StructLiteralNotAllowedHere`) * NB: This does sadly regress the compiler output for `tests/ui/parser/type-ascription-in-pattern.rs` but that can be fixed in follow-up PRs. It's not super important IMO and a natural consequence. 3. Removes code that's become dead due to the prior commit. * Basically reverts rust-lang#106620 + rust-lang#112475 (without regressing rustc's output!). * Now the older & more robust parse recovery procedure (cc `StructLiteralNotAllowedHere`) takes care of the cases the removed code used to handle. * This automatically fixes the suggestions for \[[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=7e2030163b11ee96d17adc3325b01780)\]: * `if Ty::<i32> { f: K }.m() {}`: `if Ty::<i32> { SomeStruct { f: K } }.m() {}` (broken) → ` if (Ty::<i32> { f: K }).m() {}` * `if <T as Trait>::Out { f: K::<> }.m() {}`: `if <T as Trait>(::Out { f: K::<> }).m() {}` (broken) → `if (<T as Trait>::Out { f: K::<> }).m() {}` 4. Merge and simplify UI tests pertaining to this issue, so it's easier to add more regression tests like for the two cases mentioned above. 5. Merge UI tests and add the two regression tests. Best reviewed commit by commit (on request I'll partially squash after approval).

Rollup merge of rust-lang#138898 - fmease:decrustify-parser-post-ty-ascr, r=compiler-errors Mostly parser: Eliminate code that's been dead / semi-dead since the removal of type ascription syntax **Disclaimer**: This PR is intended to mostly clean up code as opposed to bringing about behavioral changes. Therefore it doesn't aim to address any of the 'FIXME: remove after a month [dated: 2023-05-02]: "type ascription syntax has been removed, see issue [#]101728"'. --- By commit: 1. Removes truly dead code: * Since 1.71 (rust-lang#109128) `let _ = { f: x };` is a syntax error as opposed to a semantic error which allows the parse-time diagnostic (suggestion) "*struct literal body without path // you might have forgotten […]*" to kick in. * The analysis-time diagnostic (suggestion) from <=1.70 "*cannot find value \`f\` in this scope // you might have forgotten […]*" is therefore no longer reachable. 2. Updates `is_certainly_not_a_block` to be in line with the current grammar: * The seq. `{ ident:` is definitely not the start of a block. Before the removal of ty ascr, `{ ident: ty_start` would begin a block expr. * This shouldn't make more code compile IINM, it should *ultimately* only affect diagnostics. * For example, `if T { f: () } {}` will now be interpreted as an `if` with struct lit `T { f: () }` as its *condition* (which is banned in the parser anyway) as opposed to just `T` (with the *consequent* being `f : ()` which is also invalid (since 1.71)). The diagnostics are almost the same because we have two separate parse recovery procedures + diagnostics: `StructLiteralNeedingParens` (*invalid struct lit*) before and `StructLiteralNotAllowedHere` (*struct lits aren't allowed here*) now, as you can see from the diff. * (As an aside, even before this PR, fn `maybe_suggest_struct_literal` should've just used the much older & clearer `StructLiteralNotAllowedHere`) * NB: This does sadly regress the compiler output for `tests/ui/parser/type-ascription-in-pattern.rs` but that can be fixed in follow-up PRs. It's not super important IMO and a natural consequence. 3. Removes code that's become dead due to the prior commit. * Basically reverts rust-lang#106620 + rust-lang#112475 (without regressing rustc's output!). * Now the older & more robust parse recovery procedure (cc `StructLiteralNotAllowedHere`) takes care of the cases the removed code used to handle. * This automatically fixes the suggestions for \[[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=7e2030163b11ee96d17adc3325b01780)\]: * `if Ty::<i32> { f: K }.m() {}`: `if Ty::<i32> { SomeStruct { f: K } }.m() {}` (broken) → ` if (Ty::<i32> { f: K }).m() {}` * `if <T as Trait>::Out { f: K::<> }.m() {}`: `if <T as Trait>(::Out { f: K::<> }).m() {}` (broken) → `if (<T as Trait>::Out { f: K::<> }).m() {}` 4. Merge and simplify UI tests pertaining to this issue, so it's easier to add more regression tests like for the two cases mentioned above. 5. Merge UI tests and add the two regression tests. Best reviewed commit by commit (on request I'll partially squash after approval).

rustbot assigned eholk Jun 9, 2023

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 9, 2023

chenyukang commented Jun 9, 2023

View reviewed changes

chenyukang added 2 commits June 10, 2023 06:28

take care module name for suggesting surround the struct literal in p…

3983881

…arentheses

reword the message to suggest surrounding with parentheses

e3071ea

chenyukang force-pushed the yukang-fix-112278 branch from 3b8df33 to e3071ea Compare June 9, 2023 22:29

compiler-errors reviewed Jun 10, 2023

View reviewed changes

compiler/rustc_parse/src/parser/diagnostics.rs Outdated Show resolved Hide resolved

compiler-errors assigned compiler-errors and unassigned eholk Jun 10, 2023

remove unwrap

f54e757

bors added S-waiting-on-bors 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 Jun 10, 2023

matthiaskrgr mentioned this pull request Jun 10, 2023

Rollup of 7 pull requests #112512

Merged

bors merged commit e19a509 into rust-lang:master Jun 11, 2023

rustbot added this to the 1.72.0 milestone Jun 11, 2023

fmease mentioned this pull request Mar 24, 2025

Mostly parser: Eliminate code that's been dead / semi-dead since the removal of type ascription syntax #138898

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix issue for module name when surround the struct literal with parentheses #112475

Fix issue for module name when surround the struct literal with parentheses #112475

chenyukang commented Jun 9, 2023 •

edited

Loading

rustbot commented Jun 9, 2023

chenyukang Jun 9, 2023

compiler-errors Jun 10, 2023

chenyukang Jun 10, 2023

compiler-errors Jun 10, 2023

compiler-errors commented Jun 10, 2023

bors commented Jun 10, 2023

Fix issue for module name when surround the struct literal with parentheses #112475

Fix issue for module name when surround the struct literal with parentheses #112475

Conversation

chenyukang commented Jun 9, 2023 • edited Loading

rustbot commented Jun 9, 2023

chenyukang Jun 9, 2023

Choose a reason for hiding this comment

compiler-errors Jun 10, 2023

Choose a reason for hiding this comment

chenyukang Jun 10, 2023

Choose a reason for hiding this comment

compiler-errors Jun 10, 2023

Choose a reason for hiding this comment

compiler-errors commented Jun 10, 2023

bors commented Jun 10, 2023

chenyukang commented Jun 9, 2023 •

edited

Loading