-
Notifications
You must be signed in to change notification settings - Fork 70
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
Clean up operator representations #831
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed. Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:
Concerns can be lifted with:
See documentation at https://forge.rust-lang.org cc @rust-lang/compiler |
@rustbot second |
@rustbot label -final-comment-period +major-change-accepted |
…-ExprKind, r=spastorino Make `AssocOp` more like `ExprKind` This is step 1 of [MCP 831](rust-lang/compiler-team#831). r? `@estebank`
…-ExprKind, r=spastorino Make `AssocOp` more like `ExprKind` This is step 1 of [MCP 831](rust-lang/compiler-team#831). r? ``@estebank``
…-ExprKind, r=spastorino Make `AssocOp` more like `ExprKind` This is step 1 of [MCP 831](rust-lang/compiler-team#831). r? ```@estebank```
Rollup merge of rust-lang#136846 - nnethercote:make-AssocOp-more-like-ExprKind, r=spastorino Make `AssocOp` more like `ExprKind` This is step 1 of [MCP 831](rust-lang/compiler-team#831). r? ``@estebank``
…=compiler-errors Make `ast::TokenKind` more like `lexer::TokenKind` This is step 2 of rust-lang/compiler-team#831. r? `@spastorino`
Rollup merge of rust-lang#137902 - nnethercote:ast-lexer-TokenKind, r=compiler-errors Make `ast::TokenKind` more like `lexer::TokenKind` This is step 2 of rust-lang/compiler-team#831. r? `@spastorino`
Proposal
Current situation
There are several lexer and AST types that represent operators:
lex::TokenKind
,ast::TokenKind
,ast::ExprKind
,ast::AssocOp
,ast::BinOpToken
, andast::BinOpKind
. There is a lot of conceptual overlap between these types, but there are also various inconsistencies and weird things about them. It feels like the six types were created by six people that don't like each other.lex::TokenKind
andast::TokenKind
Star
,Caret
,DotDot
), good.ast::TokenKind
usesBinOp
/BinOpEq
instead of individual variants, which is different tolex::TokenKind
, yuk1.lex::TokenKind
usesBang
andast::TokenKind
usesNot
, yuk2.BinOpToken
&&
/||
and comparisons, yuk3.BinOpKind
Mul
,Rem
,Range
), good.ExprKind
ExprKind::Binary
: all theBinOpKind
variants are used, good.ExprKind::AssignOp
: only the assignable opBinOpKind
variants are used, yuk4.ExprKind::AssignOp(BinOpKind::Lt)
is expressible but invalid.lang_item_for_op
.AssocOp
ExprKind
andAssocOp
have anAssignOp
variant, good.AssocOp::AssignOp
's usesBinOpToken
, which uses syntactic names, instead ofBinOpKind
, which uses semantic names, yuk5.ExprKind
has aBinary
variant, whileAssocOp
has 10 individual variants covering those ops, yuk6.BinOpKind
names (e.g.Multiply
instead ofMul
,Modulus
instead ofRem
), yuk7.AssocOp
hasDotDot
/DotDotEq
variants butExprKind
hasRange
, yuk8.AssocOp
has anAs
variant butExprKind
hasCast
, yuk9Proposed changes
I propose to fix the nine distinct "yuk"s in three steps.
AssocOp
more likeExprKind
AssocOp::AssignOp
, useBinOpKind
instead ofBinOpToken
AssocOp::AssignOp
AssocOp::Binary
AssocOp::DotDot{,Eq}
withAssocOp::Range
AssocOp::As
asAssocOp::Cast
ast::TokenKind
more likelexer::TokenKind
ast::TokenKind::BinOp{,Eq}
and removeBinOpToken
.ast::TokenKind::Not
asast::TokenKind::Bang
.The following table summarizes the proposed changes.
In summary:
BinOpToken
is removed entirely, almost every variant ofAssocOp
changes, a lot ofast::TokenKind
variants change, one variant ofast::ExprKind
changes (AssignOp
), andlex::TokenKind
andast::BinOpToken
are unchanged.Mentors or Reviewers
I have draft code up at rust-lang/rust#134552. It's all in one PR, though I would split it into three PRs (the steps listed above) before merging.
Process
The main points of the Major Change Process are as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
The text was updated successfully, but these errors were encountered: