Skip to content

syntax: Treat error literals in more principled way - #61615

Merged
bors merged 1 commit into
rust-lang:masterfrom
petrochenkov:errlit
Jun 8, 2019
Merged

syntax: Treat error literals in more principled way#61615
bors merged 1 commit into
rust-lang:masterfrom
petrochenkov:errlit

Conversation

@petrochenkov

@petrochenkovpetrochenkov commented Jun 7, 2019

Copy link
Copy Markdown
Contributor

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 #60679 (comment) in a way

@rust-highfive

rust-highfive commented Jun 7, 2019

Copy link
Copy Markdown
Contributor

r? @eddyb

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

@rust-highfiverust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 7, 2019
@petrochenkov

petrochenkov commented Jun 7, 2019

Copy link
Copy Markdown
ContributorAuthor

r? @matklad
@bors delegate=matklad

@bors

bors commented Jun 7, 2019

Copy link
Copy Markdown
Collaborator

✌️ @matklad can now approve this pull request

@matklad

matklad commented Jun 7, 2019

Copy link
Copy Markdown
Contributor

However, I'd still want to use error literals as general purpose error tokens some day, so I kept them.

Than maybe there shouldn't be an error literal token, and just an error token?

matklad
matklad reviewed Jun 7, 2019
View reviewed changes
Comment threadsrc/libsyntax/print/pprust.rs Outdated
@petrochenkov

petrochenkov commented Jun 7, 2019

Copy link
Copy Markdown
ContributorAuthor

Than maybe there shouldn't be an error literal token, and just an error token?

Well, maybe yes in theory, but it may be more convenient to make that token a literal due to various circumstances.

  • The set of tokens understood by proc macros is closed and any extensions have to go through TokenTree::Literal.
  • The error token needs a payload Symbol which makes it very similar to a literal token.
  • If the error token needs to survive pretty-printing then some ill-formed literal may be the best choice for that.

matklad
matklad reviewed Jun 7, 2019
View reviewed changes
Comment threadsrc/libsyntax_ext/concat.rs Outdated
@matklad

matklad commented Jun 7, 2019

Copy link
Copy Markdown
Contributor

not sure about #61615 (comment), but r=me

@petrochenkov

petrochenkov commented Jun 7, 2019

Copy link
Copy Markdown
ContributorAuthor

Added a test for #61615 (comment).
@bors r=matklad rollup

@bors

bors commented Jun 7, 2019

Copy link
Copy Markdown
Collaborator

📌 Commit 2af47fa has been approved by matklad

@borsbors 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 7, 2019
Centril added a commit to Centril/rust that referenced this pull request Jun 7, 2019
@Centril
Rollup merge ofrust-lang#61615- petrochenkov:errlit, r=matklad
e3e81f4
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
@CentrilCentril mentioned this pull request Jun 7, 2019
Closed
Centril added a commit to Centril/rust that referenced this pull request Jun 7, 2019
@Centril
Rollup merge ofrust-lang#61615- petrochenkov:errlit, r=matklad
5ac8544
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
@CentrilCentril mentioned this pull request Jun 7, 2019
Closed
Centril added a commit to Centril/rust that referenced this pull request Jun 7, 2019
@Centril
Rollup merge ofrust-lang#61615- petrochenkov:errlit, r=matklad
c4285b7
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
@CentrilCentril mentioned this pull request Jun 7, 2019
Closed
Centril added a commit to Centril/rust that referenced this pull request Jun 8, 2019
@Centril
Rollup merge ofrust-lang#61615- petrochenkov:errlit, r=matklad
5062ad3
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
@CentrilCentril mentioned this pull request Jun 8, 2019
Merged
bors added a commit that referenced this pull request Jun 8, 2019
@bors
Auto merge of#61649- Centril:rollup-b4nx9k9, r=Centril
6312b89
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
@bors
bors merged commit 2af47fa into rust-lang:masterJun 8, 2019
@petrochenkov
petrochenkov deleted the errlit branch June 8, 2019 15:47
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer
@matkladmatkladmatklad left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

@eddybeddyb

Labels

S-waiting-on-borsStatus: Waiting on bors to run and complete tests. Bors will change the label on completion.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@petrochenkov@rust-highfive@bors@matklad@eddyb