-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Recover from parse error in tuple syntax #59453
Conversation
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
@@ -1,10 +1,47 @@ | |||
error: expected expression, found reserved identifier `_` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an ICE regression test, so I'm disinclined to change it to avoid the new errors.
| | ||
= help: use `::<...>` instead of `<...>` if you meant to specify type arguments | ||
= help: or use `(...)` if you meant to specify fn arguments | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These new errors are unfortunate (caused by the changes in parse_bottom_expr
) :-/
15ec821
to
5dd531e
Compare
This comment has been minimized.
This comment has been minimized.
r=me with @Centril's comments addressed or not |
5dd531e
to
9ea6790
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty happy with the changes you made. Thanks! ❤️
LL | let x = Enum::Foo(a: 3, b: 4); | ||
| ^ expecting a type here because of type ascription | ||
| | ||
= note: type ascription is a nightly-only feature that lets you annotate an expression with a type: `<expr>: <type>` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a follow up to this PR, could you point out the feature gate here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Centril, do we want to nudge people towards enabling type ascription, particularly when the most common case for this error is caused by incorrect syntax, not an attempt to use the nightly feature?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@estebank I don't think it wold be particularly invasive to point it out... It could be as simple as:
= note: #![feature(type_ascription)] lets you annotate an expression with a type: `<expr>: <type>`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment has been minimized.
This comment has been minimized.
r=me with the failing test updated |
1729d7a
to
3592079
Compare
@bors r=petrochenkov |
📌 Commit 3592079 has been approved by |
…rochenkov Recover from parse error in tuple syntax
…rochenkov Recover from parse error in tuple syntax
Rollup of 10 pull requests Successful merges: - #59376 (RFC 2008: Enum Variants) - #59453 (Recover from parse error in tuple syntax) - #59455 (Account for short-hand field syntax when suggesting borrow) - #59499 (Fix broken download link in the armhf-gnu image) - #59512 (implement `AsRawFd` for stdio locks) - #59525 (Whitelist some rustc attrs) - #59528 (Improve the dbg! macro docs ) - #59532 (In doc examples, don't ignore read/write results) - #59534 (rustdoc: collapse blanket impls in the same way as normal impls) - #59537 (Fix OnceWith docstring.) Failed merges: r? @ghost
No description provided.