-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Rollup of 7 pull requests #137709
Closed
Closed
Rollup of 7 pull requests #137709
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
…ic build dir - Introduce and use `--build-{root,test-suite-root}` over `--build-base`. - A few minor cleanups.
…test-suite-root` instead
thin_vec.as_ptr() goes through the Deref impl of ThinVec, which will not allow access to any memory as we did call set_len(0) first.
`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
Fix UB in ThinVec::flat_map_in_place `thin_vec.as_ptr()` goes through the `Deref` impl of `ThinVec`, which will not allow access to any memory as we did call `set_len(0)` first. Found in the process of investigating rust-lang#135870.
…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`
… r=BoxyUwU Pattern types: Avoid having to handle an Option for range ends in the type system or the HIR Instead, 1. during hir_ty_lowering, we now generate constants for the min/max when the range doesn't have a start/end specified. 2. in a later commit we generate those constants during ast lowering, simplifying everything further by not having to handle the range end inclusivity anymore in the type system (and thus avoiding any issues of `0..5` being different from `0..=4` I think it makes all the type system code simpler, and the cost of the extra `ConstKind::Value` processing seems negligible. r? `@BoxyUwU` cc `@joshtriplett` `@scottmcm`
…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
…oli-obk Reuse machinery from `tail_expr_drop_order` for `if_let_rescope` Namely, it defines its own `extract_component_with_significant_dtor` which is a bit more accurate than `Ty::has_significant_drop`, since it has a hard-coded list of types from the ecosystem which are opted out of the lint.[^a] Also, since we extract the dtors themselves, adopt the same *label* we use in `tail_expr_drop_order` to point out the destructor impl. This makes it much clear what's actually being dropped, so it should be clearer to know when it's a false positive. This conflicts with rust-lang#137444, but I will rebase whichever lands first. [^a]: Side-note, it's kinda a shame that now there are two functions that presumably do the same thing. But this isn't my circus, nor are these my monkeys.
@bors r+ rollup=never p=5 |
The job Click to see the possible cause of the failure (guessed by this bot)
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-compiletest
Area: The compiletest test runner
A-testsuite
Area: The testsuite used to check the correctness of rustc
rollup
A PR which is a rollup
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
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)AssocOp
more likeExprKind
#136846 (MakeAssocOp
more likeExprKind
)IntoBounds::intersect
andRangeBounds::is_empty
#137304 (addIntoBounds::intersect
andRangeBounds::is_empty
)tail_expr_drop_order
forif_let_rescope
#137455 (Reuse machinery fromtail_expr_drop_order
forif_let_rescope
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup