Skip to content

Rollup of 4 pull requests#153281

Closed
JonathanBrouwer wants to merge 12 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-r38XS7n
Closed

Rollup of 4 pull requests#153281
JonathanBrouwer wants to merge 12 commits intorust-lang:mainfrom
JonathanBrouwer:rollup-r38XS7n

Conversation

@JonathanBrouwer
Copy link
Contributor

Successful merges:

r? @ghost

Create a similar rollup

WaffleLapkin and others added 12 commits February 27, 2026 17:16
`rustc_with_all_queries` currently provides information about all
queries. Also, a caller can provide an ad hoc list of extra non-queries.
This is used by `define_queries` for non-query dep kinds: `Null`, `Red`,
etc. This is pretty hacky.

This commit changes `rustc_with_all_queries` so that the non-queries
information is available to all callers. (Some callers ignore the
non-query information.) This is done by adding `non_query` entries to
the primary list of queries in `rustc_queries!`.
Currently `define_dep_nodes` produces a macro `make_dep_kind_array` that
encodes the names of non-queries followed by queries. This macro is used
by `make_dep_kind_vtables` to make the full array of vtables, by
referring to vtable constructor functions that are put into `mod
_dep_kind_vtable_ctors`. Pretty weird!

This commit takes advantage of the previous commit's changes to
`rustc_with_all_queries`, which makes both query and non-query
information available. A new call to `rustc_with_all_queries` is used to
construct the vtable array. (This moves some dep_kind_vtable code from
`plumbing.rs` to `dep_kind_vtables.rs`, which is good.) It's
straightforward now with iterator chaining, and `mod
_dep_kind_vtable_ctors` is no longer needed.
"i.e." is short for the Latin "id est" and thus both letters should be followed
by periods.
…ice, r=lcnr

Fix next-solver ICE on PointeeSized goals

Fixes rust-lang#151957
…ueries, r=Zalathar

Rejig `rustc_with_all_queries!`

There are three things relating to `rustc_with_all_queries!` that have been bugging me.

- `rustc_with_all_queries!`'s ability to receive `extra_fake_queries` lines like `[] fn Null(()) -> (),` where the only real thing is the `Null`, and everything is just pretending to be a normal query, ugh.
- `make_dep_kind_array!`: a macro produced by one macro (`define_dep_nodes!`) and used by another macro (`define_queries!`) in another crate, ugh.
- The `_dep_kind_vtable_ctors` module, which is a special module with no actual code that serves just a way of collecting vtable constructors from two different places so they can be referred to by `make_dep_kind_array!`, ugh.

By making some adjustments to how `rustc_with_all_queries!` works, all three of these things are eliminated.

r? @Zalathar
…tuples, r=jdonszelmann

  don't emit `unused_results` lint for tuples of "trivial" types

r? @jdonszelmann
Fixes rust-lang#153144.

So it turns out rust-lang#153018 had a sneaky behavior change in the way tuples are handled and the old behavior wasn't tested.

Consider these tuples:

```rust
((), ());
((), 1);
```

Neither of them is `must_use`, so they are potential candidates for `unused_results`. So the question is whatever said tuples are considered "trivial" and thus if they end up emitting `unused_results` or not.

Here is a comparison table between PRs:
<table>
<tr><td>stable</td><td>After rust-lang#153018</td><td>After this PR</td></tr><tr><td>

```rust
((), ()); // trivial
((), 1); // trivial
```
</td>
<td>

```rust
((), ()); //~ warn: unused_results
((), 1); //~ warn: unused_results
```
</td>
<td>

```rust
((), ()); // trivial
((), 1); //~ warn: unused_results
```
</td>
</tr>
  <tr>
    <td>

tuples are trivial if **any** of their fields are trivial
    </td>
    <td>

tuples are never trivial
    </td>
    <td>

tuples are trivial if **all** of their fields are trivial
    </td>
  </tr>
</table>
vec/mod.rs: add missing period in "ie." in docs

"i.e." is short for the Latin "id est" and thus both letters should be followed by periods.
@rust-bors rust-bors bot added the rollup A PR which is a rollup label Mar 2, 2026
@rustbot rustbot added A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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. labels Mar 2, 2026
@JonathanBrouwer
Copy link
Contributor Author

@bors r+ rollup=never p=5

@rust-bors
Copy link
Contributor

rust-bors bot commented Mar 2, 2026

📌 Commit 88f8236 has been approved by JonathanBrouwer

It is now in the queue for this repository.

@rust-bors rust-bors bot 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 Mar 2, 2026
@JonathanBrouwer
Copy link
Contributor Author

Trying commonly failed jobs
@bors try jobs=test-various,x86_64-gnu-aux,x86_64-gnu-llvm-21-3,x86_64-msvc-1,aarch64-apple,x86_64-mingw-1

@rust-bors

This comment has been minimized.

rust-bors bot pushed a commit that referenced this pull request Mar 2, 2026
Rollup of 4 pull requests


try-job: test-various
try-job: x86_64-gnu-aux
try-job: x86_64-gnu-llvm-21-3
try-job: x86_64-msvc-1
try-job: aarch64-apple
try-job: x86_64-mingw-1
@rust-bors
Copy link
Contributor

rust-bors bot commented Mar 2, 2026

☀️ Try build successful (CI)
Build commit: a0464ac (a0464ac34a5d63e527d7049a9bd3c0c2e345c74f, parent: 8d50bccc5bd70be9f5a2fc98c0857e24b3dcdf85)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) 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-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.

6 participants