Skip to content
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 and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove type ascription from parser and diagnostics #109128

Merged
merged 13 commits into from
May 2, 2023

Conversation

chenyukang
Copy link
Member

Mostly based on #106826

Part of #101728

r? @estebank

@rustbot 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 Mar 14, 2023
@rustbot
Copy link
Collaborator

rustbot commented Mar 14, 2023

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@chenyukang
Copy link
Member Author

ping @Nilstrieb

@rustbot
Copy link
Collaborator

rustbot commented Mar 14, 2023

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

@chenyukang chenyukang force-pushed the yukang/remove-type-ascription branch 2 times, most recently from 3ecc00e to 466fb66 Compare March 14, 2023 23:26
@rust-log-analyzer

This comment has been minimized.

@chenyukang chenyukang force-pushed the yukang/remove-type-ascription branch from 466fb66 to 0ac6fae Compare March 15, 2023 01:38
@rust-log-analyzer

This comment has been minimized.

@chenyukang chenyukang force-pushed the yukang/remove-type-ascription branch from 0ac6fae to 83bb0e0 Compare March 15, 2023 06:58
@rust-log-analyzer

This comment has been minimized.

@chenyukang chenyukang force-pushed the yukang/remove-type-ascription branch 2 times, most recently from a4f74c6 to d0b2fc9 Compare March 15, 2023 16:58
@calebcartwright
Copy link
Member

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

@chenyukang
Copy link
Member Author

Have not had a chance to review in detail, but given the changes to expected output of formatting tests in d0b2fc9 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.

@calebcartwright
Copy link
Member

Have not had a chance to review in detail, but given the changes to expected output of formatting tests in d0b2fc9 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

@rust-log-analyzer

This comment has been minimized.

@chenyukang
Copy link
Member Author

chenyukang commented Mar 15, 2023

@calebcartwright @jyn514

I don't have much experience with rustfmt, I met some issues when resolving #109128 (comment).

how to run the rustfmt which built in stage1?
I run it directly after building:

./build/aarch64-apple-darwin/stage1-tools-bin/rustfmt

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/rustfmt

I found the file libstd-8c92ab8e515128e4.dylib located at:

.//build/aarch64-apple-darwin/stage1-std/aarch64-apple-darwin/release/deps/libstd-8c92ab8e515128e4.dylib

and 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/lib

I guess there may be a right way for it?
something like this command to link a dev rustfmt:

rustup component add rustfmt

@jyn514
Copy link
Member

jyn514 commented Mar 15, 2023

@chenyukang there's not a supported way to do this today: #102010

@bors
Copy link
Contributor

bors commented Mar 31, 2023

☔ The latest upstream changes (presumably #109010) made this pull request unmergeable. Please resolve the merge conflicts.

@chenyukang chenyukang force-pushed the yukang/remove-type-ascription branch from 0e8b6cd to dbf9825 Compare April 4, 2023 03:37
@calebcartwright
Copy link
Member

Have not had a chance to review in detail, but given the changes to expected output of formatting tests in d0b2fc9 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

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.

Comment on lines +1 to +5
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines +1 to +5
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird that we don't suggest let here :-/

Copy link
Member Author

@chenyukang chenyukang Apr 28, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current

help: maybe you meant to write an assignment here: `let temp`

is produced at here:

"maybe you meant to write an assignment 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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preexisting, note to self: this suggestion is broken

@bors

This comment was marked as outdated.

@bors
Copy link
Contributor

bors commented May 2, 2023

📌 Commit 5d1796a has been approved by iffy

It is now in the queue for this repository.

@Dylan-DPC
Copy link
Member

@bors rollup=iffy

aaaa...

@Dylan-DPC
Copy link
Member

@bors r=estebank
sorry for the mess :P

@bors
Copy link
Contributor

bors commented May 2, 2023

💡 This pull request was already approved, no need to approve it again.

@bors
Copy link
Contributor

bors commented May 2, 2023

📌 Commit 5d1796a has been approved by estebank

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented May 2, 2023

⌛ Testing commit 5d1796a with merge 98c33e4...

@bors
Copy link
Contributor

bors commented May 2, 2023

☀️ Test successful - checks-actions
Approved by: estebank
Pushing 98c33e4 to master...

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (98c33e4): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.3% [0.2%, 0.4%] 9
Regressions ❌
(secondary)
0.3% [0.2%, 0.5%] 9
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-1.4% [-1.4%, -1.4%] 1
All ❌✅ (primary) 0.3% [0.2%, 0.4%] 9

Max RSS (memory usage)

Results

This 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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.8% [1.8%, 1.8%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.7% [-4.4%, -2.1%] 5
All ❌✅ (primary) - - 0

Cycles

Results

This 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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
0.7% [0.7%, 0.7%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.6% [-2.6%, -2.6%] 1
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 655.687s -> 656.873s (0.18%)

@rustbot rustbot added the perf-regression Performance regression. label May 2, 2023
@Noratrieb
Copy link
Member

@estebank can finally be in peace 😌
thank you!

@pnkfelix
Copy link
Member

pnkfelix commented May 3, 2023

  • primary regressions are to serde, hyper, diesel; mostly to incr-unchanged scenarios.
  • surprising that this had this impact.
  • i'm guessing this is noise (this change should be solely simplifying the compiler, AFAICT).
  • marking as triaged.

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label May 3, 2023
flip1995 pushed a commit to flip1995/rust that referenced this pull request May 5, 2023
…tion, r=estebank

Remove type ascription from parser and diagnostics

Mostly based on rust-lang#106826

Part of rust-lang#101728

r? `@estebank`
compiler-errors added a commit to compiler-errors/rust that referenced this pull request May 8, 2023
…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`
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request May 9, 2023
…ilstrieb

Suggest let for possible binding with ty

Origin from rust-lang#109128 (comment)

r? `@Nilstrieb`
calebcartwright pushed a commit to calebcartwright/rust that referenced this pull request Jun 20, 2023
…tion, r=estebank

Remove type ascription from parser and diagnostics

Mostly based on rust-lang#106826

Part of rust-lang#101728

r? `@estebank`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-type_ascription `#![feature(type_ascription)]` merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.