diff options
| author | bors <bors@rust-lang.org> | 2023-03-04 16:20:28 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2023-03-04 16:20:28 +0000 |
| commit | 308d68040728254c9652adc73659dc1ad76c815c (patch) | |
| tree | 1298dea038b7310d4ab6c444d2ebf69d6ea34958 /compiler/rustc_codegen_gcc | |
| parent | d423703abae68663f49a220e382d6b6a6207ae1d (diff) | |
| parent | 03b9940b29917204d46a06393f3b4196e5efd772 (diff) | |
| download | rust-308d68040728254c9652adc73659dc1ad76c815c.tar.gz rust-308d68040728254c9652adc73659dc1ad76c815c.zip | |
Auto merge of #10442 - dtolnay-contrib:letunderscore, r=llogiq
Downgrade let_underscore_untyped to restriction From reading #6842 I am not convinced of the cost/benefit of this lint even as a pedantic lint. It sounds like the primary motivation was to catch cases of `fn() -> Result` being changed to `async fn() -> Result`. If the original Result was ignored by a `let _`, then the compiler wouldn't guide you to add `.await`. **However, this situation is caught in a more specific way by [let_underscore_future](https://rust-lang.github.io/rust-clippy/master/index.html#let_underscore_future) which was introduced _after_ the original suggestion (#9760).** In #10410 it was mentioned twice that a <kbd>restriction</kbd> lint might be more appropriate for let_underscore_untyped. changelog: Moved [`let_underscore_untyped`] to restriction
Diffstat (limited to 'compiler/rustc_codegen_gcc')
0 files changed, 0 insertions, 0 deletions