Rollup of 9 pull requests #101318
Rollup of 9 pull requests #101318
Conversation
This lint checks for statements similar to `let _ = foo`, where `foo` is a type that implements `Drop`. These types of let statements cause the expression in them to be dropped immediately, instead of at the end of the scope. Such behavior can be surprizing, especially if you are relying on the value to be dropped at the end of the scope. Instead, the binding should be an underscore prefixed name (like `_unused`) or the value should explicitly be passed to `std::mem::drop()` if the value really should be dropped immediately.
Similar to `let_underscore_drop`, this lint checks for statements similar to `let _ = foo`, where `foo` is a lock guard. These types of let statements are especially problematic because the lock gets released immediately, instead of at the end of the scope. This behavior is almost always the wrong thing.
Similar to `let_underscore_drop`, this lint checks for statements similar to `let _ = foo`, where `foo` is an expression marked `must_use`.
This was done to pass `tidy`.
These lints are very noisy and are allow-by-default in clippy anyways. Hence, setting them to allow-by-default here makes more sense than warning constantly on these cases.
This commit uses `span_suggestion_verbose` to add what specific code changes can be done as suggested by the lint--in this case, either binding the expression to an unused variable or using `std::mem::drop` to drop the value explicitly.
Clippy sets this lint to Deny by default, and it having the lint be Deny is useful for when we test the lint against a Crater run.
If the type has a trivial Drop implementation, then it is probably irrelevant that the type was dropped immediately, since nothing important happens on drop. Hence, we can bail out early instead of doing some expensive checks.
…lock` Using diagnostic items avoids having to update the paths if the guard types ever get moved around for some reason. Additionally, it also greatly simplifies the `is_sync_lock` check.
We don't actually care about running these programs, only checking the warnings they generate.
The `let_underscore_must_use` lint was really only added because clippy included it, but it doesn't actually seem very useful.
I forgot to add the diagnostic to the actual types in `std` earlier.
The "consider explicitly droping" can now suggest a machine applicable suggestion now.
This is done so that we can check the noisiness of this lint in a Crater run. Note that when I built the compiler, I actually encountered lots of places where this lint will trigger and fail compilation, so I had to also set `RUSTFLAGS_NOT_BOOSTRAP` to `-A let_underscore_drop` when compiling to prevent that.
This lint is way way too noisy to have it be `Deny` by default.
Currently, the let_underscore_lock lint simply tells what is wrong, but not why it is wrong. We fix this by using a `MultiSpan` to explain specifically that doing `let _ = ` immediately drops the lock guard because it does not assign the lock guard to a binding.
I'm not really sure why this is nessecary to do, but the checks on the PR do not seem to work if do not do this.
There are times where computing a value may be cheap, or where computing a reference may be expensive, so this fills out the possibilities.
…ref_of}` While the `provide_*` methods already short-circuit when a value has been provided, there are times where an expensive computation is needed to determine if the `provide_*` method can even be called.
rustbot
added
T-bootstrap
|
@bors r+ p=5 rollup=never |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@9353538. Direct link to PR: <rust-lang/rust#101318> 💔 miri on linux: test-pass → test-fail (cc @oli-obk @RalfJung).
|
📌 Perf builds for each rolled up PR: previous master: e21d771b9c In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (9353538): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Footnotes |
|
@rust-timer build d1db6775c125a3f8e0a0546faa427d947ea52a88 |
|
Queued d1db6775c125a3f8e0a0546faa427d947ea52a88 with parent e21d771, future comparison URL. |
|
Finished benchmarking commit (d1db6775c125a3f8e0a0546faa427d947ea52a88): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Footnotes |
rustbot
added
S-waiting-on-review
davidtwco
removed
the
A-translation
Successful merges:
let_underscorelints from clippy into rustc. #97739 (Uplift thelet_underscorelints from clippy into rustc.)#main-content > .since#101298 (rustdoc: remove unused CSS#main-content > .since)A-query-system#101304 (Add autolabels forA-query-system)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup