Skip to content
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
wants to merge 22 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

pitaj and others added 22 commits February 19, 2025 23:04
…ic build dir

- Introduce and use `--build-{root,test-suite-root}` over
  `--build-base`.
- A few minor cleanups.
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.
@rustbot rustbot added A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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. rollup A PR which is a rollup labels Feb 27, 2025
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Feb 27, 2025

📌 Commit 29c1ecf has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors 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 Feb 27, 2025
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
   Compiling compiler_builtins v0.1.148
error: const stability on the impl does not match the const stability on the trait
  --> library/core/src/pat.rs:44:13
   |
41 | /  macro_rules! impl_range_pat {
42 | |      ($($ty:ty,)*) => {
43 | |          $(
44 | |/             impl const RangePattern for $ty {
45 | ||                 const MIN: $ty = <$ty>::MIN;
46 | ||                 const MAX: $ty = <$ty>::MAX;
47 | ||                 fn sub_one(self) -> Self {
50 | ||             }
   | ||_____________^
...  |
53 | |  }
---
57 |  |     u8, u16, u32, u64, u128, usize,
58 |  | }
   |  |_- in this macro invocation
   |
note: this impl is (implicitly) stable...
   |
41 | /  macro_rules! impl_range_pat {
41 | /  macro_rules! impl_range_pat {
42 | |      ($($ty:ty,)*) => {
43 | |          $(
44 | |/             impl const RangePattern for $ty {
45 | ||                 const MIN: $ty = <$ty>::MIN;
46 | ||                 const MAX: $ty = <$ty>::MAX;
47 | ||                 fn sub_one(self) -> Self {
50 | ||             }
   | ||_____________^
...  |
53 | |  }
---

error: const stability on the impl does not match the const stability on the trait
  --> library/core/src/pat.rs:60:1
   |
60 | / impl const RangePattern for char {
61 | |     const MIN: Self = char::MIN;
62 | |
63 | |     const MAX: Self = char::MAX;
71 | | }
   | |_^
   |
   |
note: this impl is (implicitly) stable...
   |
60 | / impl const RangePattern for char {
60 | / impl const RangePattern for char {
61 | |     const MIN: Self = char::MIN;
62 | |
63 | |     const MAX: Self = char::MAX;
71 | | }
   | |_^
note: ...but the trait is unstable
  --> library/core/src/pat.rs:26:11

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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.