Rollup of 4 pull requests #137716
Closed
Rollup of 4 pull requests #137716
Conversation
This file contains hidden or 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
…ic build dir
- Introduce and use `--build-{root,test-suite-root}` over
`--build-base`.
- A few minor cleanups.
…test-suite-root` instead
`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.
[`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing Reference for overall changes: rust-lang#136437 Part **4** of **7** of the *`compiletest`-related cleanups* PR series. ### Summary - Remove `--build-base` compiletest flag, and introduce `--build-{root,test-suite-root}` flags instead. `--build-base` previously actually is test suite specific build directory, not the root `build/` directory. - Feed the root build directory directly from bootstrap to compiletest via `--build-root` instead of doing multiple layers of parent unwrapping[^parent] based on the test suite specific build directory. - Remove a redundant `to_path_buf()`. [^parent]: Please do not unwrap the parents. r? bootstrap
…o, r=compiler-errors require trait impls to have matching const stabilities as the traits This resolves rust-lang/project-const-traits#5 by implementing the suggested solution in the given thread r? ```@RalfJung``` cc ```@rust-lang/project-const-traits```
…-ExprKind, r=spastorino Make `AssocOp` more like `ExprKind` This is step 1 of [MCP 831](rust-lang/compiler-team#831). r? ```@estebank```
…ct, r=ibraheemdev add `IntoBounds::intersect` and `RangeBounds::is_empty` - ACP: rust-lang/libs-team#539 - Tracking issue for `is_empty`: rust-lang#137300 - Tracking issue for `IntoBounds`: rust-lang#136903
rustbot
added
A-compiletest
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 27, 2025
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
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💥 Test timed out |
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.
Successful merges:
compiletest-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing #136542 ([compiletest-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing)AssocOpmore likeExprKind#136846 (MakeAssocOpmore likeExprKind)IntoBounds::intersectandRangeBounds::is_empty#137304 (addIntoBounds::intersectandRangeBounds::is_empty)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup
try-job: i686-msvc-1