don't emit `unused_results` lint for tuples of "trivial" types by WaffleLapkin · Pull Request #153191 · rust-lang/rust

WaffleLapkin · 2026-02-27T16:32:33Z

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

Consider these tuples:

((),());((),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:

stable	After #153018	After this PR
((),());// trivial((),1);// trivial	((),());//~ warn: unused_results((),1);//~ warn: unused_results	((),());// trivial((),1);//~ warn: unused_results
tuples are trivial if any of their fields are trivial	tuples are never trivial	tuples are trivial if all of their fields are trivial

jdonszelmann · 2026-03-02T10:26:39Z

@bors r+ rollup

rust-bors · 2026-03-02T10:26:42Z

📌 Commit 8958cb9 has been approved by jdonszelmann

It is now in the queue for this repository.

@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>

@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>

…uwer Rollup of 5 pull requests Successful merges: - #151962 (Fix next-solver ICE on PointeeSized goals) - #153161 (Rejig `rustc_with_all_queries!`) - #152164 (Lint unused features) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs)

@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>

…uwer Rollup of 9 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute)

@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>

…uwer Rollup of 11 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

…uwer Rollup of 10 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

@jdonszelmann

Rollup merge of #153191 - WaffleLapkin:shouldnt_use_trivial_tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixes#153144. So it turns out #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 #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>

JonathanBrouwer · 2026-03-03T07:27:37Z

@rust-timer build 8958cb9

rust-timer · 2026-03-03T07:27:39Z

Missing artifact for sha 8958cb974dd6931219888d272d9b83c4db1b7a01 (https://ci-artifacts.rust-lang.org/rustc-builds/8958cb974dd6931219888d272d9b83c4db1b7a01/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T07:28:22Z

@rust-timer build 2fe8b01

rust-timer · 2026-03-03T07:28:24Z

Missing artifact for sha 2fe8b0146139e6b9aaaee3117d214e8af4ff27a4 (https://ci-artifacts.rust-lang.org/rustc-builds/2fe8b0146139e6b9aaaee3117d214e8af4ff27a4/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T08:33:34Z

@rust-timer build 5b1c8de

rust-timer · 2026-03-03T09:14:08Z

Finished benchmarking commit (5b1c8de): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 3.1%, secondary -1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.2%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	3.1%	[3.1%, 3.2%]	2

Cycles

Results (primary 3.7%, secondary 1.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.7%	[3.7%, 3.7%]	1
Regressions ❌ (secondary)	7.0%	[7.0%, 7.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	3.7%	[3.7%, 3.7%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 480.113s -> 478.877s (-0.26%)
Artifact size: 396.96 MiB -> 394.97 MiB (-0.50%)

…uwer Rollup of 10 pull requests Successful merges: - rust-lang/rust#153153 (add tests for thumb interworking) - rust-lang/rust#151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - rust-lang/rust#151962 (Fix next-solver ICE on PointeeSized goals) - rust-lang/rust#153015 (core: make atomic primitives type aliases of `Atomic<T>`) - rust-lang/rust#153161 (Rejig `rustc_with_all_queries!`) - rust-lang/rust#153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - rust-lang/rust#153273 (vec/mod.rs: add missing period in "ie." in docs) - rust-lang/rust#153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - rust-lang/rust#153293 (library: std: process: skip tests on Hermit) - rust-lang/rust#153301 (Do not ping kobzol on rustc-dev-guide changes)

WaffleLapkin · 2026-02-27T16:32:33Z

r? @jdonszelmann
Fixes#153144.

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

Consider these tuples:

((),());((),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:

stable	After #153018	After this PR
((),());// trivial((),1);// trivial	((),());//~ warn: unused_results((),1);//~ warn: unused_results	((),());// trivial((),1);//~ warn: unused_results
tuples are trivial if any of their fields are trivial	tuples are never trivial	tuples are trivial if all of their fields are trivial

jdonszelmann · 2026-03-02T10:26:39Z

@bors r+ rollup

rust-bors · 2026-03-02T10:26:42Z

📌 Commit 8958cb9 has been approved by jdonszelmann

It is now in the queue for this repository.

@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>

@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>

…uwer Rollup of 5 pull requests Successful merges: - #151962 (Fix next-solver ICE on PointeeSized goals) - #153161 (Rejig `rustc_with_all_queries!`) - #152164 (Lint unused features) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs)

@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>

…uwer Rollup of 9 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute)

@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>

…uwer Rollup of 11 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

…uwer Rollup of 10 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

@jdonszelmann

Rollup merge of #153191 - WaffleLapkin:shouldnt_use_trivial_tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixes#153144. So it turns out #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 #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>

JonathanBrouwer · 2026-03-03T07:27:37Z

@rust-timer build 8958cb9

rust-timer · 2026-03-03T07:27:39Z

Missing artifact for sha 8958cb974dd6931219888d272d9b83c4db1b7a01 (https://ci-artifacts.rust-lang.org/rustc-builds/8958cb974dd6931219888d272d9b83c4db1b7a01/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T07:28:22Z

@rust-timer build 2fe8b01

rust-timer · 2026-03-03T07:28:24Z

Missing artifact for sha 2fe8b0146139e6b9aaaee3117d214e8af4ff27a4 (https://ci-artifacts.rust-lang.org/rustc-builds/2fe8b0146139e6b9aaaee3117d214e8af4ff27a4/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T08:33:34Z

@rust-timer build 5b1c8de

rust-timer · 2026-03-03T09:14:08Z

Finished benchmarking commit (5b1c8de): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 3.1%, secondary -1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.2%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	3.1%	[3.1%, 3.2%]	2

Cycles

Results (primary 3.7%, secondary 1.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.7%	[3.7%, 3.7%]	1
Regressions ❌ (secondary)	7.0%	[7.0%, 7.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	3.7%	[3.7%, 3.7%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 480.113s -> 478.877s (-0.26%)
Artifact size: 396.96 MiB -> 394.97 MiB (-0.50%)

…uwer Rollup of 10 pull requests Successful merges: - rust-lang/rust#153153 (add tests for thumb interworking) - rust-lang/rust#151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - rust-lang/rust#151962 (Fix next-solver ICE on PointeeSized goals) - rust-lang/rust#153015 (core: make atomic primitives type aliases of `Atomic<T>`) - rust-lang/rust#153161 (Rejig `rustc_with_all_queries!`) - rust-lang/rust#153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - rust-lang/rust#153273 (vec/mod.rs: add missing period in "ie." in docs) - rust-lang/rust#153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - rust-lang/rust#153293 (library: std: process: skip tests on Hermit) - rust-lang/rust#153301 (Do not ping kobzol on rustc-dev-guide changes)

WaffleLapkin · 2026-02-27T16:32:33Z

r? @jdonszelmann
Fixes#153144.

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

Consider these tuples:

((),());((),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:

stable	After #153018	After this PR
((),());// trivial((),1);// trivial	((),());//~ warn: unused_results((),1);//~ warn: unused_results	((),());// trivial((),1);//~ warn: unused_results
tuples are trivial if any of their fields are trivial	tuples are never trivial	tuples are trivial if all of their fields are trivial

jdonszelmann · 2026-03-02T10:26:39Z

@bors r+ rollup

rust-bors · 2026-03-02T10:26:42Z

📌 Commit 8958cb9 has been approved by jdonszelmann

It is now in the queue for this repository.

@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>

@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>

…uwer Rollup of 5 pull requests Successful merges: - #151962 (Fix next-solver ICE on PointeeSized goals) - #153161 (Rejig `rustc_with_all_queries!`) - #152164 (Lint unused features) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs)

@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>

…uwer Rollup of 9 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute)

@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>

…uwer Rollup of 11 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

…uwer Rollup of 10 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

@jdonszelmann

Rollup merge of #153191 - WaffleLapkin:shouldnt_use_trivial_tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixes#153144. So it turns out #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 #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>

JonathanBrouwer · 2026-03-03T07:27:37Z

@rust-timer build 8958cb9

rust-timer · 2026-03-03T07:27:39Z

Missing artifact for sha 8958cb974dd6931219888d272d9b83c4db1b7a01 (https://ci-artifacts.rust-lang.org/rustc-builds/8958cb974dd6931219888d272d9b83c4db1b7a01/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T07:28:22Z

@rust-timer build 2fe8b01

rust-timer · 2026-03-03T07:28:24Z

Missing artifact for sha 2fe8b0146139e6b9aaaee3117d214e8af4ff27a4 (https://ci-artifacts.rust-lang.org/rustc-builds/2fe8b0146139e6b9aaaee3117d214e8af4ff27a4/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T08:33:34Z

@rust-timer build 5b1c8de

rust-timer · 2026-03-03T09:14:08Z

Finished benchmarking commit (5b1c8de): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 3.1%, secondary -1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.2%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	3.1%	[3.1%, 3.2%]	2

Cycles

Results (primary 3.7%, secondary 1.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.7%	[3.7%, 3.7%]	1
Regressions ❌ (secondary)	7.0%	[7.0%, 7.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	3.7%	[3.7%, 3.7%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 480.113s -> 478.877s (-0.26%)
Artifact size: 396.96 MiB -> 394.97 MiB (-0.50%)

…uwer Rollup of 10 pull requests Successful merges: - rust-lang/rust#153153 (add tests for thumb interworking) - rust-lang/rust#151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - rust-lang/rust#151962 (Fix next-solver ICE on PointeeSized goals) - rust-lang/rust#153015 (core: make atomic primitives type aliases of `Atomic<T>`) - rust-lang/rust#153161 (Rejig `rustc_with_all_queries!`) - rust-lang/rust#153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - rust-lang/rust#153273 (vec/mod.rs: add missing period in "ie." in docs) - rust-lang/rust#153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - rust-lang/rust#153293 (library: std: process: skip tests on Hermit) - rust-lang/rust#153301 (Do not ping kobzol on rustc-dev-guide changes)

WaffleLapkin · 2026-02-27T16:32:33Z

r? @jdonszelmann
Fixes#153144.

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

Consider these tuples:

((),());((),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:

stable	After #153018	After this PR
((),());// trivial((),1);// trivial	((),());//~ warn: unused_results((),1);//~ warn: unused_results	((),());// trivial((),1);//~ warn: unused_results
tuples are trivial if any of their fields are trivial	tuples are never trivial	tuples are trivial if all of their fields are trivial

jdonszelmann · 2026-03-02T10:26:39Z

@bors r+ rollup

rust-bors · 2026-03-02T10:26:42Z

📌 Commit 8958cb9 has been approved by jdonszelmann

It is now in the queue for this repository.

@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>

@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>

…uwer Rollup of 5 pull requests Successful merges: - #151962 (Fix next-solver ICE on PointeeSized goals) - #153161 (Rejig `rustc_with_all_queries!`) - #152164 (Lint unused features) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs)

@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>

…uwer Rollup of 9 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute)

@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>

…uwer Rollup of 11 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

…uwer Rollup of 10 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

@jdonszelmann

Rollup merge of #153191 - WaffleLapkin:shouldnt_use_trivial_tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixes#153144. So it turns out #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 #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>

JonathanBrouwer · 2026-03-03T07:27:37Z

@rust-timer build 8958cb9

rust-timer · 2026-03-03T07:27:39Z

Missing artifact for sha 8958cb974dd6931219888d272d9b83c4db1b7a01 (https://ci-artifacts.rust-lang.org/rustc-builds/8958cb974dd6931219888d272d9b83c4db1b7a01/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T07:28:22Z

@rust-timer build 2fe8b01

rust-timer · 2026-03-03T07:28:24Z

Missing artifact for sha 2fe8b0146139e6b9aaaee3117d214e8af4ff27a4 (https://ci-artifacts.rust-lang.org/rustc-builds/2fe8b0146139e6b9aaaee3117d214e8af4ff27a4/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T08:33:34Z

@rust-timer build 5b1c8de

rust-timer · 2026-03-03T09:14:08Z

Finished benchmarking commit (5b1c8de): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 3.1%, secondary -1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.2%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	3.1%	[3.1%, 3.2%]	2

Cycles

Results (primary 3.7%, secondary 1.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.7%	[3.7%, 3.7%]	1
Regressions ❌ (secondary)	7.0%	[7.0%, 7.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	3.7%	[3.7%, 3.7%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 480.113s -> 478.877s (-0.26%)
Artifact size: 396.96 MiB -> 394.97 MiB (-0.50%)

…uwer Rollup of 10 pull requests Successful merges: - rust-lang/rust#153153 (add tests for thumb interworking) - rust-lang/rust#151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - rust-lang/rust#151962 (Fix next-solver ICE on PointeeSized goals) - rust-lang/rust#153015 (core: make atomic primitives type aliases of `Atomic<T>`) - rust-lang/rust#153161 (Rejig `rustc_with_all_queries!`) - rust-lang/rust#153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - rust-lang/rust#153273 (vec/mod.rs: add missing period in "ie." in docs) - rust-lang/rust#153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - rust-lang/rust#153293 (library: std: process: skip tests on Hermit) - rust-lang/rust#153301 (Do not ping kobzol on rustc-dev-guide changes)

WaffleLapkin · 2026-02-27T16:32:33Z

r? @jdonszelmann
Fixes#153144.

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

Consider these tuples:

((),());((),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:

stable	After #153018	After this PR
((),());// trivial((),1);// trivial	((),());//~ warn: unused_results((),1);//~ warn: unused_results	((),());// trivial((),1);//~ warn: unused_results
tuples are trivial if any of their fields are trivial	tuples are never trivial	tuples are trivial if all of their fields are trivial

jdonszelmann · 2026-03-02T10:26:39Z

@bors r+ rollup

rust-bors · 2026-03-02T10:26:42Z

📌 Commit 8958cb9 has been approved by jdonszelmann

It is now in the queue for this repository.

@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>

@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>

…uwer Rollup of 5 pull requests Successful merges: - #151962 (Fix next-solver ICE on PointeeSized goals) - #153161 (Rejig `rustc_with_all_queries!`) - #152164 (Lint unused features) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs)

@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>

…uwer Rollup of 9 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute)

@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>

…uwer Rollup of 11 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

…uwer Rollup of 10 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

@jdonszelmann

Rollup merge of #153191 - WaffleLapkin:shouldnt_use_trivial_tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixes#153144. So it turns out #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 #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>

JonathanBrouwer · 2026-03-03T07:27:37Z

@rust-timer build 8958cb9

rust-timer · 2026-03-03T07:27:39Z

Missing artifact for sha 8958cb974dd6931219888d272d9b83c4db1b7a01 (https://ci-artifacts.rust-lang.org/rustc-builds/8958cb974dd6931219888d272d9b83c4db1b7a01/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T07:28:22Z

@rust-timer build 2fe8b01

rust-timer · 2026-03-03T07:28:24Z

Missing artifact for sha 2fe8b0146139e6b9aaaee3117d214e8af4ff27a4 (https://ci-artifacts.rust-lang.org/rustc-builds/2fe8b0146139e6b9aaaee3117d214e8af4ff27a4/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T08:33:34Z

@rust-timer build 5b1c8de

rust-timer · 2026-03-03T09:14:08Z

Finished benchmarking commit (5b1c8de): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 3.1%, secondary -1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.2%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	3.1%	[3.1%, 3.2%]	2

Cycles

Results (primary 3.7%, secondary 1.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.7%	[3.7%, 3.7%]	1
Regressions ❌ (secondary)	7.0%	[7.0%, 7.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	3.7%	[3.7%, 3.7%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 480.113s -> 478.877s (-0.26%)
Artifact size: 396.96 MiB -> 394.97 MiB (-0.50%)

…uwer Rollup of 10 pull requests Successful merges: - rust-lang/rust#153153 (add tests for thumb interworking) - rust-lang/rust#151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - rust-lang/rust#151962 (Fix next-solver ICE on PointeeSized goals) - rust-lang/rust#153015 (core: make atomic primitives type aliases of `Atomic<T>`) - rust-lang/rust#153161 (Rejig `rustc_with_all_queries!`) - rust-lang/rust#153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - rust-lang/rust#153273 (vec/mod.rs: add missing period in "ie." in docs) - rust-lang/rust#153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - rust-lang/rust#153293 (library: std: process: skip tests on Hermit) - rust-lang/rust#153301 (Do not ping kobzol on rustc-dev-guide changes)

WaffleLapkin · 2026-02-27T16:32:33Z

r? @jdonszelmann
Fixes#153144.

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

Consider these tuples:

((),());((),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:

stable	After #153018	After this PR
((),());// trivial((),1);// trivial	((),());//~ warn: unused_results((),1);//~ warn: unused_results	((),());// trivial((),1);//~ warn: unused_results
tuples are trivial if any of their fields are trivial	tuples are never trivial	tuples are trivial if all of their fields are trivial

jdonszelmann · 2026-03-02T10:26:39Z

@bors r+ rollup

rust-bors · 2026-03-02T10:26:42Z

📌 Commit 8958cb9 has been approved by jdonszelmann

It is now in the queue for this repository.

@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>

@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>

…uwer Rollup of 5 pull requests Successful merges: - #151962 (Fix next-solver ICE on PointeeSized goals) - #153161 (Rejig `rustc_with_all_queries!`) - #152164 (Lint unused features) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs)

@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>

…uwer Rollup of 9 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute)

@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>

…uwer Rollup of 11 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

…uwer Rollup of 10 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

@jdonszelmann

Rollup merge of #153191 - WaffleLapkin:shouldnt_use_trivial_tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixes#153144. So it turns out #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 #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>

JonathanBrouwer · 2026-03-03T07:27:37Z

@rust-timer build 8958cb9

rust-timer · 2026-03-03T07:27:39Z

Missing artifact for sha 8958cb974dd6931219888d272d9b83c4db1b7a01 (https://ci-artifacts.rust-lang.org/rustc-builds/8958cb974dd6931219888d272d9b83c4db1b7a01/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T07:28:22Z

@rust-timer build 2fe8b01

rust-timer · 2026-03-03T07:28:24Z

Missing artifact for sha 2fe8b0146139e6b9aaaee3117d214e8af4ff27a4 (https://ci-artifacts.rust-lang.org/rustc-builds/2fe8b0146139e6b9aaaee3117d214e8af4ff27a4/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T08:33:34Z

@rust-timer build 5b1c8de

rust-timer · 2026-03-03T09:14:08Z

Finished benchmarking commit (5b1c8de): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 3.1%, secondary -1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.2%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	3.1%	[3.1%, 3.2%]	2

Cycles

Results (primary 3.7%, secondary 1.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.7%	[3.7%, 3.7%]	1
Regressions ❌ (secondary)	7.0%	[7.0%, 7.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	3.7%	[3.7%, 3.7%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 480.113s -> 478.877s (-0.26%)
Artifact size: 396.96 MiB -> 394.97 MiB (-0.50%)

…uwer Rollup of 10 pull requests Successful merges: - rust-lang/rust#153153 (add tests for thumb interworking) - rust-lang/rust#151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - rust-lang/rust#151962 (Fix next-solver ICE on PointeeSized goals) - rust-lang/rust#153015 (core: make atomic primitives type aliases of `Atomic<T>`) - rust-lang/rust#153161 (Rejig `rustc_with_all_queries!`) - rust-lang/rust#153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - rust-lang/rust#153273 (vec/mod.rs: add missing period in "ie." in docs) - rust-lang/rust#153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - rust-lang/rust#153293 (library: std: process: skip tests on Hermit) - rust-lang/rust#153301 (Do not ping kobzol on rustc-dev-guide changes)

WaffleLapkin · 2026-02-27T16:32:33Z

r? @jdonszelmann
Fixes#153144.

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

Consider these tuples:

((),());((),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:

stable	After #153018	After this PR
((),());// trivial((),1);// trivial	((),());//~ warn: unused_results((),1);//~ warn: unused_results	((),());// trivial((),1);//~ warn: unused_results
tuples are trivial if any of their fields are trivial	tuples are never trivial	tuples are trivial if all of their fields are trivial

jdonszelmann · 2026-03-02T10:26:39Z

@bors r+ rollup

rust-bors · 2026-03-02T10:26:42Z

📌 Commit 8958cb9 has been approved by jdonszelmann

It is now in the queue for this repository.

@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>

@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>

…uwer Rollup of 5 pull requests Successful merges: - #151962 (Fix next-solver ICE on PointeeSized goals) - #153161 (Rejig `rustc_with_all_queries!`) - #152164 (Lint unused features) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs)

@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>

…uwer Rollup of 9 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute)

@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>

…uwer Rollup of 11 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

…uwer Rollup of 10 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

@jdonszelmann

Rollup merge of #153191 - WaffleLapkin:shouldnt_use_trivial_tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixes#153144. So it turns out #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 #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>

JonathanBrouwer · 2026-03-03T07:27:37Z

@rust-timer build 8958cb9

rust-timer · 2026-03-03T07:27:39Z

Missing artifact for sha 8958cb974dd6931219888d272d9b83c4db1b7a01 (https://ci-artifacts.rust-lang.org/rustc-builds/8958cb974dd6931219888d272d9b83c4db1b7a01/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T07:28:22Z

@rust-timer build 2fe8b01

rust-timer · 2026-03-03T07:28:24Z

Missing artifact for sha 2fe8b0146139e6b9aaaee3117d214e8af4ff27a4 (https://ci-artifacts.rust-lang.org/rustc-builds/2fe8b0146139e6b9aaaee3117d214e8af4ff27a4/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T08:33:34Z

@rust-timer build 5b1c8de

rust-timer · 2026-03-03T09:14:08Z

Finished benchmarking commit (5b1c8de): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 3.1%, secondary -1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.2%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	3.1%	[3.1%, 3.2%]	2

Cycles

Results (primary 3.7%, secondary 1.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.7%	[3.7%, 3.7%]	1
Regressions ❌ (secondary)	7.0%	[7.0%, 7.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	3.7%	[3.7%, 3.7%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 480.113s -> 478.877s (-0.26%)
Artifact size: 396.96 MiB -> 394.97 MiB (-0.50%)

…uwer Rollup of 10 pull requests Successful merges: - rust-lang/rust#153153 (add tests for thumb interworking) - rust-lang/rust#151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - rust-lang/rust#151962 (Fix next-solver ICE on PointeeSized goals) - rust-lang/rust#153015 (core: make atomic primitives type aliases of `Atomic<T>`) - rust-lang/rust#153161 (Rejig `rustc_with_all_queries!`) - rust-lang/rust#153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - rust-lang/rust#153273 (vec/mod.rs: add missing period in "ie." in docs) - rust-lang/rust#153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - rust-lang/rust#153293 (library: std: process: skip tests on Hermit) - rust-lang/rust#153301 (Do not ping kobzol on rustc-dev-guide changes)

WaffleLapkin · 2026-02-27T16:32:33Z

r? @jdonszelmann
Fixes#153144.

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

Consider these tuples:

((),());((),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:

stable	After #153018	After this PR
((),());// trivial((),1);// trivial	((),());//~ warn: unused_results((),1);//~ warn: unused_results	((),());// trivial((),1);//~ warn: unused_results
tuples are trivial if any of their fields are trivial	tuples are never trivial	tuples are trivial if all of their fields are trivial

jdonszelmann · 2026-03-02T10:26:39Z

@bors r+ rollup

rust-bors · 2026-03-02T10:26:42Z

📌 Commit 8958cb9 has been approved by jdonszelmann

It is now in the queue for this repository.

@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>

@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>

…uwer Rollup of 5 pull requests Successful merges: - #151962 (Fix next-solver ICE on PointeeSized goals) - #153161 (Rejig `rustc_with_all_queries!`) - #152164 (Lint unused features) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs)

@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>

…uwer Rollup of 9 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute)

@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>

…uwer Rollup of 11 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #149328 (Add `String<A>` type with custom allocator parameter) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

…uwer Rollup of 10 pull requests Successful merges: - #153153 (add tests for thumb interworking) - #151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - #151962 (Fix next-solver ICE on PointeeSized goals) - #153015 (core: make atomic primitives type aliases of `Atomic<T>`) - #153161 (Rejig `rustc_with_all_queries!`) - #153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - #153273 (vec/mod.rs: add missing period in "ie." in docs) - #153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - #153293 (library: std: process: skip tests on Hermit) - #153301 (Do not ping kobzol on rustc-dev-guide changes)

@jdonszelmann

Rollup merge of #153191 - WaffleLapkin:shouldnt_use_trivial_tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmannFixes#153144. So it turns out #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 #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>

JonathanBrouwer · 2026-03-03T07:27:37Z

@rust-timer build 8958cb9

rust-timer · 2026-03-03T07:27:39Z

Missing artifact for sha 8958cb974dd6931219888d272d9b83c4db1b7a01 (https://ci-artifacts.rust-lang.org/rustc-builds/8958cb974dd6931219888d272d9b83c4db1b7a01/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T07:28:22Z

@rust-timer build 2fe8b01

rust-timer · 2026-03-03T07:28:24Z

Missing artifact for sha 2fe8b0146139e6b9aaaee3117d214e8af4ff27a4 (https://ci-artifacts.rust-lang.org/rustc-builds/2fe8b0146139e6b9aaaee3117d214e8af4ff27a4/rustc-nightly-x86_64-unknown-linux-gnu.tar.xz); not built yet, try again later.

JonathanBrouwer · 2026-03-03T08:33:34Z

@rust-timer build 5b1c8de

rust-timer · 2026-03-03T09:14:08Z

Finished benchmarking commit (5b1c8de): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 3.1%, secondary -1.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.1%	[3.1%, 3.2%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	3.1%	[3.1%, 3.2%]	2

Cycles

Results (primary 3.7%, secondary 1.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	3.7%	[3.7%, 3.7%]	1
Regressions ❌ (secondary)	7.0%	[7.0%, 7.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-3.1%, -3.1%]	1
All ❌✅ (primary)	3.7%	[3.7%, 3.7%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 480.113s -> 478.877s (-0.26%)
Artifact size: 396.96 MiB -> 394.97 MiB (-0.50%)

…uwer Rollup of 10 pull requests Successful merges: - rust-lang/rust#153153 (add tests for thumb interworking) - rust-lang/rust#151780 (Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`) - rust-lang/rust#151962 (Fix next-solver ICE on PointeeSized goals) - rust-lang/rust#153015 (core: make atomic primitives type aliases of `Atomic<T>`) - rust-lang/rust#153161 (Rejig `rustc_with_all_queries!`) - rust-lang/rust#153191 ( don't emit `unused_results` lint for tuples of "trivial" types ) - rust-lang/rust#153273 (vec/mod.rs: add missing period in "ie." in docs) - rust-lang/rust#153292 (tests: codegen-llvm: vec-calloc: do not require the uwtable attribute) - rust-lang/rust#153293 (library: std: process: skip tests on Hermit) - rust-lang/rust#153301 (Do not ping kobzol on rustc-dev-guide changes)

add more tests for unused_results lints
d351448

rustbot assigned jdonszelmann Feb 27, 2026

rustbot added 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. labels Feb 27, 2026

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

WaffleLapkin force-pushed the shouldnt_use_trivial_tuples branch from 621c007 to 8958cb9Compare February 27, 2026 16:41

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

JonathanBrouwer mentioned this pull request Mar 2, 2026
Rollup of 4 pull requests #153281
Closed

JonathanBrouwer mentioned this pull request Mar 2, 2026
Rollup of 5 pull requests #153284
Closed

JonathanBrouwer mentioned this pull request Mar 2, 2026
Rollup of 9 pull requests #153299
Closed

JonathanBrouwer mentioned this pull request Mar 2, 2026
Rollup of 11 pull requests #153303
Closed

JonathanBrouwer mentioned this pull request Mar 2, 2026
Rollup of 10 pull requests #153304
Merged

rust-borsBot merged commit 2fe8b01 into rust-lang:mainMar 2, 2026
11 checks passed

rustbot added this to the 1.96.0 milestone Mar 2, 2026

This comment has been minimized.
Sign in to view

WaffleLapkin deleted the shouldnt_use_trivial_tuples branch March 3, 2026 12:03