syntax: Treat error literals in more principled way #61615
Merged
Conversation
This file contains 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
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
✌️ @matklad can now approve this pull request |
Than maybe there shouldn't be an error literal token, and just an error token? |
matklad
reviewed
Jun 7, 2019
Well, maybe yes in theory, but it may be more convenient to make that token a literal due to various circumstances.
|
matklad
reviewed
Jun 7, 2019
|
not sure about #61615 (comment), but r=me |
|
Added a test for #61615 (comment). |
|
📌 Commit 2af47fa has been approved by |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 7, 2019
syntax: Treat error literals in more principled way Free them from their character literal origins. I actually tried to remove `LitKind::Err` entirely (by converting it into `ExprKind::Err` immediately), and it caused no diagnostic regressions in the test suite. However, I'd still want to use error literals as general purpose error tokens some day, so I kept them. The downside of having `LitKind::Err` in addition to `ExprKind::Err` is that every time you want to do something with `ExprKind::Err` you need to make sure that `ExprKind::Lit(LitKind::Err)` is treated in the same way. Fortunately, this usually happens automatically because both literals and errors are "leaf" expressions, however this PR does fix a couple of inconsistencies between them. Addresses rust-lang#60679 (comment) in a way
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 7, 2019
syntax: Treat error literals in more principled way Free them from their character literal origins. I actually tried to remove `LitKind::Err` entirely (by converting it into `ExprKind::Err` immediately), and it caused no diagnostic regressions in the test suite. However, I'd still want to use error literals as general purpose error tokens some day, so I kept them. The downside of having `LitKind::Err` in addition to `ExprKind::Err` is that every time you want to do something with `ExprKind::Err` you need to make sure that `ExprKind::Lit(LitKind::Err)` is treated in the same way. Fortunately, this usually happens automatically because both literals and errors are "leaf" expressions, however this PR does fix a couple of inconsistencies between them. Addresses rust-lang#60679 (comment) in a way
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 7, 2019
syntax: Treat error literals in more principled way Free them from their character literal origins. I actually tried to remove `LitKind::Err` entirely (by converting it into `ExprKind::Err` immediately), and it caused no diagnostic regressions in the test suite. However, I'd still want to use error literals as general purpose error tokens some day, so I kept them. The downside of having `LitKind::Err` in addition to `ExprKind::Err` is that every time you want to do something with `ExprKind::Err` you need to make sure that `ExprKind::Lit(LitKind::Err)` is treated in the same way. Fortunately, this usually happens automatically because both literals and errors are "leaf" expressions, however this PR does fix a couple of inconsistencies between them. Addresses rust-lang#60679 (comment) in a way
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 8, 2019
syntax: Treat error literals in more principled way Free them from their character literal origins. I actually tried to remove `LitKind::Err` entirely (by converting it into `ExprKind::Err` immediately), and it caused no diagnostic regressions in the test suite. However, I'd still want to use error literals as general purpose error tokens some day, so I kept them. The downside of having `LitKind::Err` in addition to `ExprKind::Err` is that every time you want to do something with `ExprKind::Err` you need to make sure that `ExprKind::Lit(LitKind::Err)` is treated in the same way. Fortunately, this usually happens automatically because both literals and errors are "leaf" expressions, however this PR does fix a couple of inconsistencies between them. Addresses rust-lang#60679 (comment) in a way
bors
added a commit
that referenced
this pull request
Jun 8, 2019
Rollup of 7 pull requests Successful merges: - #61223 (Document tuple's Ord behavior as sequential) - #61615 (syntax: Treat error literals in more principled way) - #61616 (parser: Remove `Deref` impl from `Parser`) - #61621 (Clarify when we run steps with ONLY_HOSTS) - #61627 (Add regression test for #61452.) - #61641 (Revert "Make LocalAnalizer visitor iterate instead of recurse") - #61647 (Use stable wrappers in f32/f64::signum) Failed merges: r? @ghost
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Free them from their character literal origins.
I actually tried to remove
LitKind::Errentirely (by converting it intoExprKind::Errimmediately), and it caused no diagnostic regressions in the test suite.However, I'd still want to use error literals as general purpose error tokens some day, so I kept them.
The downside of having
LitKind::Errin addition toExprKind::Erris that every time you want to do something withExprKind::Erryou need to make sure thatExprKind::Lit(LitKind::Err)is treated in the same way.Fortunately, this usually happens automatically because both literals and errors are "leaf" expressions, however this PR does fix a couple of inconsistencies between them.
Addresses #60679 (comment) in a way