don't emit unused_results lint for tuples of "trivial" types #153191
don't emit unused_results lint for tuples of "trivial" types #153191rust-bors[bot] merged 2 commits intorust-lang:mainfrom
unused_results lint for tuples of "trivial" types #153191Conversation
621c007 to
8958cb9
Compare
|
@bors r+ rollup |
…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmann Fixes rust-lang#153144. So it turns out rust-lang#153018 had a sneaky behavior change in the way tuples are handled and the old behavior wasn't tested. Consider these tuples: ```rust ((), ()); ((), 1); ``` Neither of them is `must_use`, so they are potential candidates for `unused_results`. So the question is whatever said tuples are considered "trivial" and thus if they end up emitting `unused_results` or not. Here is a comparison table between PRs: <table> <tr><td>stable</td><td>After rust-lang#153018</td><td>After this PR</td></tr><tr><td> ```rust ((), ()); // trivial ((), 1); // trivial ``` </td> <td> ```rust ((), ()); //~ warn: unused_results ((), 1); //~ warn: unused_results ``` </td> <td> ```rust ((), ()); // trivial ((), 1); //~ warn: unused_results ``` </td> </tr> <tr> <td> tuples are trivial if **any** of their fields are trivial </td> <td> tuples are never trivial </td> <td> tuples are trivial if **all** of their fields are trivial </td> </tr> </table>
…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmann Fixes rust-lang#153144. So it turns out rust-lang#153018 had a sneaky behavior change in the way tuples are handled and the old behavior wasn't tested. Consider these tuples: ```rust ((), ()); ((), 1); ``` Neither of them is `must_use`, so they are potential candidates for `unused_results`. So the question is whatever said tuples are considered "trivial" and thus if they end up emitting `unused_results` or not. Here is a comparison table between PRs: <table> <tr><td>stable</td><td>After rust-lang#153018</td><td>After this PR</td></tr><tr><td> ```rust ((), ()); // trivial ((), 1); // trivial ``` </td> <td> ```rust ((), ()); //~ warn: unused_results ((), 1); //~ warn: unused_results ``` </td> <td> ```rust ((), ()); // trivial ((), 1); //~ warn: unused_results ``` </td> </tr> <tr> <td> tuples are trivial if **any** of their fields are trivial </td> <td> tuples are never trivial </td> <td> tuples are trivial if **all** of their fields are trivial </td> </tr> </table>
…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)
…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)
…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)
…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmann Fixes rust-lang#153144. So it turns out rust-lang#153018 had a sneaky behavior change in the way tuples are handled and the old behavior wasn't tested. Consider these tuples: ```rust ((), ()); ((), 1); ``` Neither of them is `must_use`, so they are potential candidates for `unused_results`. So the question is whatever said tuples are considered "trivial" and thus if they end up emitting `unused_results` or not. Here is a comparison table between PRs: <table> <tr><td>stable</td><td>After rust-lang#153018</td><td>After this PR</td></tr><tr><td> ```rust ((), ()); // trivial ((), 1); // trivial ``` </td> <td> ```rust ((), ()); //~ warn: unused_results ((), 1); //~ warn: unused_results ``` </td> <td> ```rust ((), ()); // trivial ((), 1); //~ warn: unused_results ``` </td> </tr> <tr> <td> tuples are trivial if **any** of their fields are trivial </td> <td> tuples are never trivial </td> <td> tuples are trivial if **all** of their fields are trivial </td> </tr> </table>
…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)
…tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types r? @jdonszelmann Fixes rust-lang#153144. So it turns out rust-lang#153018 had a sneaky behavior change in the way tuples are handled and the old behavior wasn't tested. Consider these tuples: ```rust ((), ()); ((), 1); ``` Neither of them is `must_use`, so they are potential candidates for `unused_results`. So the question is whatever said tuples are considered "trivial" and thus if they end up emitting `unused_results` or not. Here is a comparison table between PRs: <table> <tr><td>stable</td><td>After rust-lang#153018</td><td>After this PR</td></tr><tr><td> ```rust ((), ()); // trivial ((), 1); // trivial ``` </td> <td> ```rust ((), ()); //~ warn: unused_results ((), 1); //~ warn: unused_results ``` </td> <td> ```rust ((), ()); // trivial ((), 1); //~ warn: unused_results ``` </td> </tr> <tr> <td> tuples are trivial if **any** of their fields are trivial </td> <td> tuples are never trivial </td> <td> tuples are trivial if **all** of their fields are trivial </td> </tr> </table>
…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)
Rollup merge of #153191 - WaffleLapkin:shouldnt_use_trivial_tuples, r=jdonszelmann don't emit `unused_results` lint for tuples of "trivial" types 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: ```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>
|
@rust-timer build 8958cb9 |
|
Missing artifact for sha |
|
@rust-timer build 2fe8b01 |
|
Missing artifact for sha |
|
@rust-timer build 5b1c8de |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (5b1c8de): comparison URL. Overall result: ❌✅ regressions and improvements - no action neededBenchmarking 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 Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
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.
CyclesResults (primary 3.7%, secondary 1.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 480.113s -> 478.877s (-0.26%) |
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:
Neither of them is
must_use, so they are potential candidates forunused_results. So the question is whatever said tuples are considered "trivial" and thus if they end up emittingunused_resultsor not.Here is a comparison table between PRs:
tuples are trivial if any of their fields are trivial
tuples are never trivial
tuples are trivial if all of their fields are trivial