Rollup of 4 pull requests by JonathanBrouwer · Pull Request #153281 · rust-lang/rust

JonathanBrouwer · 2026-03-02T12:05:19Z

Successful merges:

Fix next-solver ICE on PointeeSized goals #151962 (Fix next-solver ICE on PointeeSized goals)
Rejig rustc_with_all_queries! #153161 (Rejig rustc_with_all_queries!)
don't emit unused_results lint for tuples of "trivial" types #153191 ( don't emit unused_results lint for tuples of "trivial" types )
vec/mod.rs: add missing period in "ie." in docs #153273 (vec/mod.rs: add missing period in "ie." in docs)

`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.

remove *

…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

@Zalathar

…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

@jdonszelmann

…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixesrust-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.

JonathanBrouwer · 2026-03-02T12:05:28Z

@bors r+ rollup=never p=5

rust-bors · 2026-03-02T12:05:31Z

📌 Commit 88f8236 has been approved by JonathanBrouwer

It is now in the queue for this repository.

JonathanBrouwer · 2026-03-02T12:05:40Z

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

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 · 2026-03-02T15:22:57Z

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

JonathanBrouwer · 2026-03-02T12:05:19Z

Successful merges:

Fix next-solver ICE on PointeeSized goals #151962 (Fix next-solver ICE on PointeeSized goals)
Rejig rustc_with_all_queries! #153161 (Rejig rustc_with_all_queries!)
don't emit unused_results lint for tuples of "trivial" types #153191 ( don't emit unused_results lint for tuples of "trivial" types )
vec/mod.rs: add missing period in "ie." in docs #153273 (vec/mod.rs: add missing period in "ie." in docs)

r? @ghost

Create a similar rollup

`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.

remove *

…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

@Zalathar

…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

@jdonszelmann

…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixesrust-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.

JonathanBrouwer · 2026-03-02T12:05:28Z

@bors r+ rollup=never p=5

rust-bors · 2026-03-02T12:05:31Z

📌 Commit 88f8236 has been approved by JonathanBrouwer

It is now in the queue for this repository.

JonathanBrouwer · 2026-03-02T12:05:40Z

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

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 · 2026-03-02T15:22:57Z

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

JonathanBrouwer · 2026-03-02T12:05:19Z

Successful merges:

Fix next-solver ICE on PointeeSized goals #151962 (Fix next-solver ICE on PointeeSized goals)
Rejig rustc_with_all_queries! #153161 (Rejig rustc_with_all_queries!)
don't emit unused_results lint for tuples of "trivial" types #153191 ( don't emit unused_results lint for tuples of "trivial" types )
vec/mod.rs: add missing period in "ie." in docs #153273 (vec/mod.rs: add missing period in "ie." in docs)

r? @ghost

Create a similar rollup

`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.

remove *

…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

@Zalathar

…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

@jdonszelmann

…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixesrust-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.

JonathanBrouwer · 2026-03-02T12:05:28Z

@bors r+ rollup=never p=5

rust-bors · 2026-03-02T12:05:31Z

📌 Commit 88f8236 has been approved by JonathanBrouwer

It is now in the queue for this repository.

JonathanBrouwer · 2026-03-02T12:05:40Z

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

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 · 2026-03-02T15:22:57Z

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

JonathanBrouwer · 2026-03-02T12:05:19Z

Successful merges:

Fix next-solver ICE on PointeeSized goals #151962 (Fix next-solver ICE on PointeeSized goals)
Rejig rustc_with_all_queries! #153161 (Rejig rustc_with_all_queries!)
don't emit unused_results lint for tuples of "trivial" types #153191 ( don't emit unused_results lint for tuples of "trivial" types )
vec/mod.rs: add missing period in "ie." in docs #153273 (vec/mod.rs: add missing period in "ie." in docs)

r? @ghost

Create a similar rollup

`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.

remove *

…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

@Zalathar

…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

@jdonszelmann

…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixesrust-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.

JonathanBrouwer · 2026-03-02T12:05:28Z

@bors r+ rollup=never p=5

rust-bors · 2026-03-02T12:05:31Z

📌 Commit 88f8236 has been approved by JonathanBrouwer

It is now in the queue for this repository.

JonathanBrouwer · 2026-03-02T12:05:40Z

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

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 · 2026-03-02T15:22:57Z

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

JonathanBrouwer · 2026-03-02T12:05:19Z

Successful merges:

Fix next-solver ICE on PointeeSized goals #151962 (Fix next-solver ICE on PointeeSized goals)
Rejig rustc_with_all_queries! #153161 (Rejig rustc_with_all_queries!)
don't emit unused_results lint for tuples of "trivial" types #153191 ( don't emit unused_results lint for tuples of "trivial" types )
vec/mod.rs: add missing period in "ie." in docs #153273 (vec/mod.rs: add missing period in "ie." in docs)

r? @ghost

Create a similar rollup

`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.

remove *

…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

@Zalathar

…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

@jdonszelmann

…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixesrust-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.

JonathanBrouwer · 2026-03-02T12:05:28Z

@bors r+ rollup=never p=5

rust-bors · 2026-03-02T12:05:31Z

📌 Commit 88f8236 has been approved by JonathanBrouwer

It is now in the queue for this repository.

JonathanBrouwer · 2026-03-02T12:05:40Z

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

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 · 2026-03-02T15:22:57Z

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

JonathanBrouwer · 2026-03-02T12:05:19Z

Successful merges:

Fix next-solver ICE on PointeeSized goals #151962 (Fix next-solver ICE on PointeeSized goals)
Rejig rustc_with_all_queries! #153161 (Rejig rustc_with_all_queries!)
don't emit unused_results lint for tuples of "trivial" types #153191 ( don't emit unused_results lint for tuples of "trivial" types )
vec/mod.rs: add missing period in "ie." in docs #153273 (vec/mod.rs: add missing period in "ie." in docs)

r? @ghost

Create a similar rollup

`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.

remove *

…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

@Zalathar

…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

@jdonszelmann

…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixesrust-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.

JonathanBrouwer · 2026-03-02T12:05:28Z

@bors r+ rollup=never p=5

rust-bors · 2026-03-02T12:05:31Z

📌 Commit 88f8236 has been approved by JonathanBrouwer

It is now in the queue for this repository.

JonathanBrouwer · 2026-03-02T12:05:40Z

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

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 · 2026-03-02T15:22:57Z

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

JonathanBrouwer · 2026-03-02T12:05:19Z

Successful merges:

Fix next-solver ICE on PointeeSized goals #151962 (Fix next-solver ICE on PointeeSized goals)
Rejig rustc_with_all_queries! #153161 (Rejig rustc_with_all_queries!)
don't emit unused_results lint for tuples of "trivial" types #153191 ( don't emit unused_results lint for tuples of "trivial" types )
vec/mod.rs: add missing period in "ie." in docs #153273 (vec/mod.rs: add missing period in "ie." in docs)

r? @ghost

Create a similar rollup

`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.

remove *

…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

@Zalathar

…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

@jdonszelmann

…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixesrust-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.

JonathanBrouwer · 2026-03-02T12:05:28Z

@bors r+ rollup=never p=5

rust-bors · 2026-03-02T12:05:31Z

📌 Commit 88f8236 has been approved by JonathanBrouwer

It is now in the queue for this repository.

JonathanBrouwer · 2026-03-02T12:05:40Z

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

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 · 2026-03-02T15:22:57Z

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

JonathanBrouwer · 2026-03-02T12:05:19Z

Successful merges:

Fix next-solver ICE on PointeeSized goals #151962 (Fix next-solver ICE on PointeeSized goals)
Rejig rustc_with_all_queries! #153161 (Rejig rustc_with_all_queries!)
don't emit unused_results lint for tuples of "trivial" types #153191 ( don't emit unused_results lint for tuples of "trivial" types )
vec/mod.rs: add missing period in "ie." in docs #153273 (vec/mod.rs: add missing period in "ie." in docs)

r? @ghost

Create a similar rollup

`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.

remove *

…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

@Zalathar

…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

@jdonszelmann

…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixesrust-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.

JonathanBrouwer · 2026-03-02T12:05:28Z

@bors r+ rollup=never p=5

rust-bors · 2026-03-02T12:05:31Z

📌 Commit 88f8236 has been approved by JonathanBrouwer

It is now in the queue for this repository.

JonathanBrouwer · 2026-03-02T12:05:40Z

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

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 · 2026-03-02T15:22:57Z

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

WaffleLapkinand others added 12 commits February 27, 2026 17:16

add more tests for unused_results lints
d351448

don't emit unused_results lint for tuples of trivial types
8958cb9

vec/mod.rs: add missing period in "ie." in docs
f538526
"i.e." is short for the Latin "id est" and thus both letters should be followed by periods.

fix next-solver ICE on PointeeSized goals
66786fc

replace issue number with link
6cda9bf

simplify test case and add revisions for both solvers
ca74063
remove *

Rollup merge ofrust-lang#151962- TaKO8Ki:pointee-sized-next-solver-…
fe2ef56
…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

Rollup merge ofrust-lang#153273- DanielEScherzer:patch-2, r=joboet
88f8236
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-borsBot added the rollup A PR which is a rollup label Mar 2, 2026

rust-borsBot 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

This comment has been minimized.
Sign in to view

JonathanBrouwer closed this Mar 2, 2026

JonathanBrouwer deleted the rollup-r38XS7n branch August 21, 2026 08:28

WaffleLapkinand others added 12 commits February 27, 2026 17:16

add more tests for unused_results lints
d351448

don't emit unused_results lint for tuples of trivial types
8958cb9

vec/mod.rs: add missing period in "ie." in docs
f538526
"i.e." is short for the Latin "id est" and thus both letters should be followed by periods.

fix next-solver ICE on PointeeSized goals
66786fc

replace issue number with link
6cda9bf

simplify test case and add revisions for both solvers
ca74063
remove *

Rollup merge ofrust-lang#151962- TaKO8Ki:pointee-sized-next-solver-…
fe2ef56
…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

Rollup merge ofrust-lang#153273- DanielEScherzer:patch-2, r=joboet
88f8236
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-borsBot added the rollup A PR which is a rollup label Mar 2, 2026

rust-borsBot 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

This comment has been minimized.
Sign in to view

JonathanBrouwer closed this Mar 2, 2026

JonathanBrouwer deleted the rollup-r38XS7n branch August 21, 2026 08:28

WaffleLapkinand others added 12 commits February 27, 2026 17:16

add more tests for unused_results lints
d351448

don't emit unused_results lint for tuples of trivial types
8958cb9

vec/mod.rs: add missing period in "ie." in docs
f538526
"i.e." is short for the Latin "id est" and thus both letters should be followed by periods.

fix next-solver ICE on PointeeSized goals
66786fc

replace issue number with link
6cda9bf

simplify test case and add revisions for both solvers
ca74063
remove *

Rollup merge ofrust-lang#151962- TaKO8Ki:pointee-sized-next-solver-…
fe2ef56
…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

Rollup merge ofrust-lang#153273- DanielEScherzer:patch-2, r=joboet
88f8236
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-borsBot added the rollup A PR which is a rollup label Mar 2, 2026

rust-borsBot 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

This comment has been minimized.
Sign in to view

JonathanBrouwer closed this Mar 2, 2026

JonathanBrouwer deleted the rollup-r38XS7n branch August 21, 2026 08:28

WaffleLapkinand others added 12 commits February 27, 2026 17:16

add more tests for unused_results lints
d351448

don't emit unused_results lint for tuples of trivial types
8958cb9

vec/mod.rs: add missing period in "ie." in docs
f538526
"i.e." is short for the Latin "id est" and thus both letters should be followed by periods.

fix next-solver ICE on PointeeSized goals
66786fc

replace issue number with link
6cda9bf

simplify test case and add revisions for both solvers
ca74063
remove *

Rollup merge ofrust-lang#151962- TaKO8Ki:pointee-sized-next-solver-…
fe2ef56
…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

Rollup merge ofrust-lang#153273- DanielEScherzer:patch-2, r=joboet
88f8236
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-borsBot added the rollup A PR which is a rollup label Mar 2, 2026

rust-borsBot 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

This comment has been minimized.
Sign in to view

JonathanBrouwer closed this Mar 2, 2026

JonathanBrouwer deleted the rollup-r38XS7n branch August 21, 2026 08:28

WaffleLapkinand others added 12 commits February 27, 2026 17:16

add more tests for unused_results lints
d351448

don't emit unused_results lint for tuples of trivial types
8958cb9

vec/mod.rs: add missing period in "ie." in docs
f538526
"i.e." is short for the Latin "id est" and thus both letters should be followed by periods.

fix next-solver ICE on PointeeSized goals
66786fc

replace issue number with link
6cda9bf

simplify test case and add revisions for both solvers
ca74063
remove *

Rollup merge ofrust-lang#151962- TaKO8Ki:pointee-sized-next-solver-…
fe2ef56
…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

Rollup merge ofrust-lang#153273- DanielEScherzer:patch-2, r=joboet
88f8236
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-borsBot added the rollup A PR which is a rollup label Mar 2, 2026

rust-borsBot 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

This comment has been minimized.
Sign in to view

JonathanBrouwer closed this Mar 2, 2026

JonathanBrouwer deleted the rollup-r38XS7n branch August 21, 2026 08:28

WaffleLapkinand others added 12 commits February 27, 2026 17:16

add more tests for unused_results lints
d351448

don't emit unused_results lint for tuples of trivial types
8958cb9

vec/mod.rs: add missing period in "ie." in docs
f538526
"i.e." is short for the Latin "id est" and thus both letters should be followed by periods.

fix next-solver ICE on PointeeSized goals
66786fc

replace issue number with link
6cda9bf

simplify test case and add revisions for both solvers
ca74063
remove *

Rollup merge ofrust-lang#151962- TaKO8Ki:pointee-sized-next-solver-…
fe2ef56
…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

Rollup merge ofrust-lang#153273- DanielEScherzer:patch-2, r=joboet
88f8236
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-borsBot added the rollup A PR which is a rollup label Mar 2, 2026

rust-borsBot 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

This comment has been minimized.
Sign in to view

JonathanBrouwer closed this Mar 2, 2026

JonathanBrouwer deleted the rollup-r38XS7n branch August 21, 2026 08:28

WaffleLapkinand others added 12 commits February 27, 2026 17:16

add more tests for unused_results lints
d351448

don't emit unused_results lint for tuples of trivial types
8958cb9

vec/mod.rs: add missing period in "ie." in docs
f538526
"i.e." is short for the Latin "id est" and thus both letters should be followed by periods.

fix next-solver ICE on PointeeSized goals
66786fc

replace issue number with link
6cda9bf

simplify test case and add revisions for both solvers
ca74063
remove *

Rollup merge ofrust-lang#151962- TaKO8Ki:pointee-sized-next-solver-…
fe2ef56
…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

Rollup merge ofrust-lang#153273- DanielEScherzer:patch-2, r=joboet
88f8236
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-borsBot added the rollup A PR which is a rollup label Mar 2, 2026

rust-borsBot 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

This comment has been minimized.
Sign in to view

JonathanBrouwer closed this Mar 2, 2026

JonathanBrouwer deleted the rollup-r38XS7n branch August 21, 2026 08:28

WaffleLapkinand others added 12 commits February 27, 2026 17:16

add more tests for unused_results lints
d351448

don't emit unused_results lint for tuples of trivial types
8958cb9

vec/mod.rs: add missing period in "ie." in docs
f538526
"i.e." is short for the Latin "id est" and thus both letters should be followed by periods.

fix next-solver ICE on PointeeSized goals
66786fc

replace issue number with link
6cda9bf

simplify test case and add revisions for both solvers
ca74063
remove *

Rollup merge ofrust-lang#151962- TaKO8Ki:pointee-sized-next-solver-…
fe2ef56
…ice, r=lcnr Fix next-solver ICE on PointeeSized goals Fixesrust-lang#151957

Rollup merge ofrust-lang#153273- DanielEScherzer:patch-2, r=joboet
88f8236
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-borsBot added the rollup A PR which is a rollup label Mar 2, 2026

rust-borsBot 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

This comment has been minimized.
Sign in to view

JonathanBrouwer closed this Mar 2, 2026

JonathanBrouwer deleted the rollup-r38XS7n branch August 21, 2026 08:28

Uh oh!

Uh oh!

Conversation

JonathanBrouwer commented Mar 2, 2026

Uh oh!

JonathanBrouwer commented Mar 2, 2026

Uh oh!

rust-borsBot commented Mar 2, 2026

Uh oh!

JonathanBrouwer commented Mar 2, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Uh oh!

Conversation

JonathanBrouwer commented Mar 2, 2026

Uh oh!

JonathanBrouwer commented Mar 2, 2026

Uh oh!

rust-borsBot commented Mar 2, 2026

Uh oh!

JonathanBrouwer commented Mar 2, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Uh oh!

Conversation

JonathanBrouwer commented Mar 2, 2026

Uh oh!

JonathanBrouwer commented Mar 2, 2026

Uh oh!

rust-borsBot commented Mar 2, 2026

Uh oh!

JonathanBrouwer commented Mar 2, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Mar 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Uh oh!

Conversation

JonathanBrouwer commented Mar 2, 2026

Uh oh!

JonathanBrouwer commented Mar 2, 2026

Uh oh!

rust-borsBot commented Mar 2, 2026

Uh oh!

JonathanBrouwer commented Mar 2, 2026

Uh oh!

This comment has been minimized.

rust-borsBot commented Mar 2, 2026

Uh oh!