Rollup of 10 pull requests #92880
Closed
Rollup of 10 pull requests #92880
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…elid,xFrednet Update pulldown-cmark version to 0.9 Fixes rust-lang#92206. r? `@camelid`
Clippy helpfully warns about code like this, telling you that you
probably meant "write_all":
fn say_hi<W:Write>(w: &mut W) {
w.write(b"hello").unwrap();
}
This patch attempts to extend the lint so it also covers this
case:
async fn say_hi<W:AsyncWrite>(w: &mut W) {
w.write(b"hello").await.unwrap();
}
(I've run into this second case several times in my own programming,
and so have my coworkers, so unless we're especially accident-prone
in this area, it's probably worth addressing?)
This patch covers the Async{Read,Write}Ext traits in futures-rs,
and in tokio, since both are quite widely used.
changelog: [`unused_io_amount`] now supports AsyncReadExt and AsyncWriteExt.
This improves the quality of the genrated output and makes it more in line with other lint messages. changelog: [`unused_io_amount`]: Improve help text
…Frednet
Extend unused_io_amount to cover async io.
Clippy helpfully warns about code like this, telling you that you
probably meant "write_all":
fn say_hi<W:Write>(w: &mut W) {
w.write(b"hello").unwrap();
}
This patch attempts to extend the lint so it also covers this
case:
async fn say_hi<W:AsyncWrite>(w: &mut W) {
w.write(b"hello").await.unwrap();
}
(I've run into this second case several times in my own programming,
and so have my coworkers, so unless we're especially accident-prone
in this area, it's probably worth addressing?)
Since this is my first attempt at a clippy patch, I've probably
made all kinds of mistakes: please help me fix them? I'd like
to learn more here.
Open questions I have:
* Should this be a separate lint from unused_io_amount? Maybe
unused_async_io_amount? If so, how should I structure their
shared code?
* Should this cover tokio's AsyncWrite too?
* Is it okay to write lints for stuff that isn't part of
the standard library? I see that "regex" also has lints,
and I figure that "futures" is probably okay too, since it's
an official rust-lang repository.
* What other tests are needed?
* How should I improve the code?
Thanks for your time!
---
changelog: [`unused_io_amount`] now supports async read and write traits
…earth fix [`redundant_closure`] fp with `Rc<F>`/`Arc<F>` fixes rust-lang#8073 changelog: don't trigger [`redundant_closure`] on `Arc<F>` or `Rc<F>`
The `wrong_self_convention` lint uses a `SelfKind` type to decide
whether a method has the right kind of "self" for its name, or whether
the kind of "self" it has makes its name confusable for a method in
a common trait. One possibility is `SelfKind::No`, which is supposed
to mean "No `self`".
Previously, SelfKind::No matched everything _except_ Self, including
references to Self. This patch changes it to match Self, &Self, &mut
Self, Box<Self>, and so on.
For example, this kind of method was allowed before:
```
impl S {
// Should trigger the lint, because
// "methods called `is_*` usually take `self` by reference or no `self`"
fn is_foo(&mut self) -> bool { todo!() }
}
```
But since SelfKind::No matched "&mut self", no lint was triggered
(see rust-lang#8142).
With this patch, the code above now gives a lint as expected.
Fixes rust-lang#8142
changelog: [`wrong_self_convention`] rejects `self` references in more cases
Remove existing problematic cases.
Inspired by a discussion in rust-lang/rust-clippy#8197 --- r? `@llogiq` changelog: none The lint is this on nightly, therefore no changelog entry for you xD
…uct, r=llogiq return_self_not_must_use document `#[must_use]` on the type Inspired by a discussion in rust-lang/rust-clippy#8197 --- r? `@llogiq` changelog: none The lint is this on nightly, therefore no changelog entry for you xD
wrong_self_convention: Match `SelfKind::No` more restrictively
The `wrong_self_convention` lint uses a `SelfKind` type to decide
whether a method has the right kind of "self" for its name, or whether
the kind of "self" it has makes its name confusable for a method in
a common trait. One possibility is `SelfKind::No`, which is supposed
to mean "No `self`".
Previously, SelfKind::No matched everything _except_ Self, including
references to Self. This patch changes it to match Self, &Self, &mut
Self, Box<Self>, and so on.
For example, this kind of method was allowed before:
```
impl S {
// Should trigger the lint, because
// "methods called `is_*` usually take `self` by reference or no `self`"
fn is_foo(&mut self) -> bool { todo!() }
}
```
But since SelfKind::No matched "&mut self", no lint was triggered
(see rust-lang#8142).
With this patch, the code above now gives a lint as expected.
fixes rust-lang#8142
changelog: [`wrong_self_convention`] rejects `self` references in more cases
…xFrednet [`erasing_op`] lint ignored when operation `Output` type is different from the type of constant `0` fixes rust-lang#7210 changelog: [`erasing_op`] lint ignored when operation `Output` type is different from the type of constant `0`
Remove `NullOp::Box` Follow up of rust-lang#89030 and MCP rust-lang/compiler-team#460. ~1 month later nothing seems to be broken, apart from a small regression that rust-lang#89332 (1aac85bb716c09304b313d69d30d74fe7e8e1a8e) shows could be regained by remvoing the diverging path, so it shall be safe to continue and remove `NullOp::Box` completely. r? `@jonas-schievink` `@rustbot` label T-compiler
…rednet
Fix `clippy::use-self`` warning in ` src/main.rs`
`ClippyCmd` warnings gets generated due to addition of `clippy::use-self`. This PR fixes that.
```
warning: unnecessary structure name repetition
--> src/main.rs:99:9
|
99 | ClippyCmd {
| ^^^^^^^^^ help: use the applicable keyword: `Self`
|
= note: `-W clippy::use-self` implied by `-W clippy::nursery`
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#use_self
```
---
changelog: none
Consider auto-deref when linting `manual_swap` fixes rust-lang#8154 changelog: Don't lint `manual_swap` when a field access involves auto-deref
Allow `_` as the length of array types and repeat expressions r? `@BoxyUwU` cc `@varkor`
changelog: none Sorry, this is a big one. A lot of interrelated changes and I wanted to put the new utils to use to make sure they are somewhat battle-tested. We may want to divide some of the lint-specific refactoring commits into batches for smaller reviewing tasks. I could also split into more PRs. Introduces a bunch of new utils at `clippy_utils::macros::...`. Please read through the docs and give any feedback! I'm happy to introduce `MacroCall` and various functions to retrieve an instance. It feels like the missing puzzle piece. I'm also introducing `ExpnId` from rustc as "useful for Clippy too". `@rust-lang/clippy` Fixes rust-lang#7843 by not parsing every node of macro implementations, at least the major offenders. I probably want to get rid of `is_expn_of` at some point.
New macro utils changelog: none Sorry, this is a big one. A lot of interrelated changes and I wanted to put the new utils to use to make sure they are somewhat battle-tested. We may want to divide some of the lint-specific refactoring commits into batches for smaller reviewing tasks. I could also split into more PRs. Introduces a bunch of new utils at `clippy_utils::macros::...`. Please read through the docs and give any feedback! I'm happy to introduce `MacroCall` and various functions to retrieve an instance. It feels like the missing puzzle piece. I'm also introducing `ExpnId` from rustc as "useful for Clippy too". `@rust-lang/clippy` Fixes rust-lang#7843 by not parsing every node of macro implementations, at least the major offenders. I probably want to get rid of `is_expn_of` at some point.
Remove in_macro from clippy_utils changelog: none Previously done in rust-lang#7897 but reverted in rust-lang#8170. I'd like to keep `in_macro` out of utils because if a span is from expansion in any way (desugaring or macro), we should not proceed without understanding the nature of the expansion IMO. r? `@llogiq`
…woerister Implement raw-dylib support for windows-gnu Add support for `#[link(kind = "raw-dylib")]` on windows-gnu targets. Work around binutils's linker's inability to read import libraries produced by LLVM by calling out to the binutils `dlltool` utility to create an import library from a temporary .DEF file; this approach is effectively a slightly refined version of ``@mati865's`` earlier attempt at this strategy in PR rust-lang#88801. (In particular, this attempt at this strategy adds support for `#[link_ordinal(...)]` as well.) In support of rust-lang#58713.
Don't fall back to crate-level opaque type definitions. That would just hide bugs, as it works accidentally if the opaque type is defined at the crate level. Only works after rust-lang#90948 which worked by accident for our entire test suite.
… r=Mark-Simulacrum
Partially stabilize `maybe_uninit_extra`
This covers:
```rust
impl<T> MaybeUninit<T> {
pub unsafe fn assume_init_read(&self) -> T { ... }
pub unsafe fn assume_init_drop(&mut self) { ... }
}
```
It does not cover the const-ness of `write` under `const_maybe_uninit_write` nor the const-ness of `assume_init_read` (this commit adds `const_maybe_uninit_assume_init_read` for that).
FCP: rust-lang#63567 (comment).
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
…ef-suggestion, r=camelid Deduplicate box deref and regular deref suggestions Remove the suggestion code special-cased for Box deref. r? ``@camelid`` since you introduced the code in rust-lang#90627
…r=camelid Update documentation for doc_cfg feature Fixes rust-lang#92484.
…-Simulacrum Clean up some links in RELEASES This fixes some issues with markdown links in the RELEASES file.
Fix some lints documentation Several lints documentation failed to show the output of the example (mostly due to `ignore` attribute): - [irrefutable_let_patterns](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#irrefutable-let-patterns) - [asm_sub_register](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#asm-sub-register) - [bad_asm_style](https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#bad-asm-style) - [ineffective_unstable_trait_impl](https://doc.rust-lang.org/rustc/lints/listing/deny-by-default.html#ineffective-unstable-trait-impl) - duplicate_macro_attributes This pull request fixes these lints output so that they can be displayed properly.
Clippyup r? ``@Manishearth``
…Gomez Use the updated Rust logo in rustdoc This pull-request use the updated Rust logo from rust-lang/rust-artwork#9 and also change the logo format from PNG to SVG. | Before | After | | --- | --- | |  |  | I also took the liberty to update the two PNG favicons with the SVG reducing their size by ~35% each. Fixes rust-lang#92831 r? ``@jsha``
Fix a missing dot in the main item heading This pull-request fix a missing `·` in the item header ~~and also make use of ` ` to explicit that the spaces are mandatory~~. | Before | After | | --- | --- | |  |  | PS: This was introduce yesterday by rust-lang#92526 (the migration from Tera to Askama) and is not currently observable in the nightly doc.
rustbot
added
T-compiler
|
@bors r+ rollup=never p=10 |
|
📌 Commit a5ac242 has been approved by |
bors
added
the
S-waiting-on-bors
|
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message |
bors
added
S-waiting-on-author
|
☔ The latest upstream changes (presumably #92844) made this pull request unmergeable. Please resolve the merge conflicts. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
maybe_uninit_extra#92768 (Partially stabilizemaybe_uninit_extra)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup