Remove type ascription from parser and diagnostics #109128
Conversation
rustbot
added
S-waiting-on-review
|
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
|
ping @Nilstrieb |
|
Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt |
chenyukang
force-pushed
the
yukang/remove-type-ascription
branch
2 times, most recently
from
3ecc00e to
466fb66
Compare
This comment has been minimized.
This comment has been minimized.
chenyukang
force-pushed
the
yukang/remove-type-ascription
branch
from
466fb66 to
0ac6fae
Compare
This comment has been minimized.
This comment has been minimized.
chenyukang
force-pushed
the
yukang/remove-type-ascription
branch
from
0ac6fae to
83bb0e0
Compare
This comment has been minimized.
This comment has been minimized.
chenyukang
force-pushed
the
yukang/remove-type-ascription
branch
2 times, most recently
from
a4f74c6 to
d0b2fc9
Compare
|
Have not had a chance to review in detail, but given the changes to expected output of formatting tests in d0b2fc96f919dd4a923ce5ea7538a82fec5e2bdc I want t-rustfmt to have an opportunity to review before merging to ensure the currently proposed changes in this PR do not contain something that would violate rustfmt's formatting stability guarantee |
sure, I checked the diff, and we can not support macro with ascription syntax now. |
Understood, and don't mean to imply there's any issues. Just leaving a note so that this doesn't get merged before we get an opportunity to review |
This comment has been minimized.
This comment has been minimized.
|
I don't have much experience with how to run the I got this error: dyld[10473]: Library not loaded: @rpath/libstd-8c92ab8e515128e4.dylib
Referenced from: <2F10C189-2C7F-3447-943C-6509EEC9465A> /Users/yukang/rust/build/aarch64-apple-darwin/stage1-tools-bin/rustfmt
Reason: tried: '/Users/yukang/rust/build/aarch64-apple-darwin/stage1/lib/libstd-8c92ab8e515128e4.dylib' (no such file), .......
[1] 10473 abort ./build/aarch64-apple-darwin/stage1-tools-bin/rustfmtI found the file libstd-8c92ab8e515128e4.dylib located at: .//build/aarch64-apple-darwin/stage1-std/aarch64-apple-darwin/release/deps/libstd-8c92ab8e515128e4.dyliband I workaround it in this naive way: export DYLD_LIBRARY_PATH="$(rustc +dev --print sysroot)/lib"
cp .//build/aarch64-apple-darwin/stage1-std/aarch64-apple-darwin/release/deps/libstd-8c92ab8e515128e4.dylib /Users/yukang/rust/build/aarch64-apple-darwin/stage1/libI guess there may be a right way for it? rustup component add rustfmt |
|
@chenyukang there's not a supported way to do this today: #102010 |
|
☔ The latest upstream changes (presumably #109010) made this pull request unmergeable. Please resolve the merge conflicts. |
chenyukang
force-pushed
the
yukang/remove-type-ascription
branch
from
0e8b6cd to
dbf9825
Compare
Apologies for the late follow up but no concerns from my end wrt rustfmt changes. The diff looked odd at first blush but the reasoning became clear after refreshing my memory on part of the test contents that weren't part of the diff. |
| error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `:` | ||
| --> $DIR/type-ascription-precedence.rs:27:7 | ||
| | | ||
| LL | &(S: &S); | ||
| | ^ expected `&S`, found `S` | ||
| LL | &S: &S; | ||
| | ^ expected one of 8 possible tokens |
There was a problem hiding this comment.
I wonder if it makes sense to leave enough logic in the parser to detect at least :: -> : and ;-> : typos (the later is caught in the test below, but it isn't triggering here, maybe because it is in the same line?). We might also want to leave enough for type ascription parsing with a hard error saying "this used to be parsed but it no longer is" but that is much lower priority (so we can disregard my thought there).
There was a problem hiding this comment.
I think we can disregard this, the other positive tests are catching it, so we should be ok.
| | | ||
| = note: `#![feature(type_ascription)]` lets you annotate an expression with a type: `<expr>: <type>` | ||
| = note: type ascription syntax has been removed, see issue #101728 <https://github.com/rust-lang/rust/issues/101728> |
There was a problem hiding this comment.
Should we soften the wording here with something like "if you meant to annotate an expression with a type, the type ascription syntax has been removed". Someone who encounters the note without knowing what it was might be left a bit baffled.
| error: expected identifier, found `:` | ||
| --> $DIR/type-ascription-instead-of-let.rs:5:13 | ||
| | | ||
| LL | temp: i32 = fun(5i32); | ||
| | ^^^^ | ||
| | | | ||
| | not found in this scope | ||
| | help: maybe you meant to write an assignment here: `let temp` | ||
| | ^ expected identifier |
There was a problem hiding this comment.
Weird that we don't suggest let here :-/
There was a problem hiding this comment.
The current
help: maybe you meant to write an assignment here: `let temp`is produced at here:
but the function type_ascription_suggestion is removed.
So it's a preexisting issue, now we only support this scenario:
4 | a = 1;
| ^
|
help: you might have meant to introduce a new binding
|
4 | let a = 1;
| +++I think we should extend to the scenario of a: i32 = 1, I will fix it in another PR.
| @@ -29,5 +18,5 @@ LL - bar(baz: $rest) | |||
| LL + bar(: $rest) | |||
There was a problem hiding this comment.
Preexisting, note to self: this suggestion is broken
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (98c33e4): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 655.687s -> 656.873s (0.18%) |
|
@estebank can finally be in peace 😌 |
@rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
…tion, r=estebank Remove type ascription from parser and diagnostics Mostly based on rust-lang#106826 Part of rust-lang#101728 r? `@estebank`
…ompiler-errors Suggest struct when we get colon in fileds in enum A follow-up fix for rust-lang#109128 From: rust-lang#109128 (comment) r? `@estebank`
…ilstrieb Suggest let for possible binding with ty Origin from rust-lang#109128 (comment) r? `@Nilstrieb`
…tion, r=estebank Remove type ascription from parser and diagnostics Mostly based on rust-lang#106826 Part of rust-lang#101728 r? `@estebank`
…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).
parser: Remove old diagnostic notes for type ascription syntax Type ascription syntax was removed by rust-lang#109128 in 2023, so “remove this again in a few months” is long overdue. Happily, this also reduces the amount of parser diagnostic code that cares whether the compiler is unstable. --- See also the recent rust-lang#138898, which removed some other related dead code but declined to touch the diagnostics. It's possible that some of these parser tests are no longer useful at all, but I haven't investigated them for this PR.
parser: Remove old diagnostic notes for type ascription syntax Type ascription syntax was removed by rust-lang#109128 in 2023, so “remove this again in a few months” is long overdue. Happily, this also reduces the amount of parser diagnostic code that cares whether the compiler is unstable. --- See also the recent rust-lang#138898, which removed some other related dead code but declined to touch the diagnostics. It's possible that some of these parser tests are no longer useful at all, but I haven't investigated them for this PR.
Rollup merge of rust-lang#139908 - Zalathar:no-ascription, r=jieyouxu parser: Remove old diagnostic notes for type ascription syntax Type ascription syntax was removed by rust-lang#109128 in 2023, so “remove this again in a few months” is long overdue. Happily, this also reduces the amount of parser diagnostic code that cares whether the compiler is unstable. --- See also the recent rust-lang#138898, which removed some other related dead code but declined to touch the diagnostics. It's possible that some of these parser tests are no longer useful at all, but I haven't investigated them for this PR.
Mostly based on #106826
Part of #101728
r? @estebank