-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Make AssocOp
more like ExprKind
#136846
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Make AssocOp
more like ExprKind
#136846
Conversation
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
☔ The latest upstream changes (presumably #136878) made this pull request unmergeable. Please resolve the merge conflicts. |
The conflicts are trivial and won't affect review, so I will wait before fixing them. |
1ec80bc
to
22c1d74
Compare
It has been two weeks, let's try a different reviewer. r? @spastorino |
☔ The latest upstream changes (presumably #135726) made this pull request unmergeable. Please resolve the merge conflicts. |
`AssocOp::AssignOp` contains a `BinOpToken`. `ExprKind::AssignOp` contains a `BinOpKind`. Given that `AssocOp` is basically a cut-down version of `ExprKind`, it makes sense to make `AssocOp` more like `ExprKind`. Especially given that `AssocOp` and `BinOpKind` use semantic operation names (e.g. `Mul`, `Div`), but `BinOpToken` uses syntactic names (e.g. `Star`, `Slash`). This results in more concise code, and removes the need for various conversions. (Note that the removed functions `hirbinop2assignop` and `astbinop2assignop` are semantically identical, because `hir::BinOp` is just a synonum for `ast::BinOp`!) The only downside to this is that it allows the possibility of some nonsensical combinations, such as `AssocOp::AssignOp(BinOpKind::Lt)`. But `ExprKind::AssignOp` already has that problem. The problem can be fixed for both types in the future with some effort, by introducing an `AssignOpKind` type.
It mirrors `ExprKind::Binary`, and contains a `BinOpKind`. This makes `AssocOp` more like `ExprKind`. Note that the variants removed from `AssocOp` are all named differently to `BinOpToken`, e.g. `Multiply` instead of `Mul`, so that's an inconsistency removed. The commit adds `precedence` and `fixity` methods to `BinOpKind`, and calls them from the corresponding methods in `AssocOp`. This avoids the need to create an `AssocOp` from a `BinOpKind` in a bunch of places, and `AssocOp::from_ast_binop` is removed. `AssocOp::to_ast_binop` is also no longer needed. Overall things are shorter and nicer.
It makes `AssocOp` more similar to `ExprKind` and makes things a little simpler. And the semantic names make more sense here than the syntactic names.
To match `ExprKind::Cast`, and because a semantic name makes more sense here than a syntactic name.
22c1d74
to
2ac46f6
Compare
@bors r+ |
…-ExprKind, r=spastorino Make `AssocOp` more like `ExprKind` This is step 1 of [MCP 831](rust-lang/compiler-team#831). r? `@estebank`
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#136542 ([`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing) - rust-lang#136579 (Fix UB in ThinVec::flat_map_in_place) - rust-lang#136688 (require trait impls to have matching const stabilities as the traits) - rust-lang#136846 (Make `AssocOp` more like `ExprKind`) - rust-lang#137304 (add `IntoBounds::intersect` and `RangeBounds::is_empty`) - rust-lang#137455 (Reuse machinery from `tail_expr_drop_order` for `if_let_rescope`) - rust-lang#137480 (Return unexpected termination error instead of panicing in `Thread::join`) - rust-lang#137694 (Spruce up `AttributeKind` docs) r? `@ghost` `@rustbot` modify labels: rollup
…-ExprKind, r=spastorino Make `AssocOp` more like `ExprKind` This is step 1 of [MCP 831](rust-lang/compiler-team#831). r? ```@estebank```
Rollup of 4 pull requests Successful merges: - rust-lang#136542 ([`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing) - rust-lang#136688 (require trait impls to have matching const stabilities as the traits) - rust-lang#136846 (Make `AssocOp` more like `ExprKind`) - rust-lang#137304 (add `IntoBounds::intersect` and `RangeBounds::is_empty`) r? `@ghost` `@rustbot` modify labels: rollup try-job: i686-msvc-1
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#136542 ([`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing) - rust-lang#136579 (Fix UB in ThinVec::flat_map_in_place) - rust-lang#136688 (require trait impls to have matching const stabilities as the traits) - rust-lang#136846 (Make `AssocOp` more like `ExprKind`) - rust-lang#137304 (add `IntoBounds::intersect` and `RangeBounds::is_empty`) - rust-lang#137455 (Reuse machinery from `tail_expr_drop_order` for `if_let_rescope`) - rust-lang#137480 (Return unexpected termination error instead of panicing in `Thread::join`) - rust-lang#137694 (Spruce up `AttributeKind` docs) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#136542 ([`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing) - rust-lang#136579 (Fix UB in ThinVec::flat_map_in_place) - rust-lang#136688 (require trait impls to have matching const stabilities as the traits) - rust-lang#136846 (Make `AssocOp` more like `ExprKind`) - rust-lang#137304 (add `IntoBounds::intersect` and `RangeBounds::is_empty`) - rust-lang#137455 (Reuse machinery from `tail_expr_drop_order` for `if_let_rescope`) - rust-lang#137480 (Return unexpected termination error instead of panicing in `Thread::join`) - rust-lang#137694 (Spruce up `AttributeKind` docs) r? `@ghost` `@rustbot` modify labels: rollup
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``
This is step 1 of MCP 831.
r? @estebank