Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add [unnecessary_reserve] lint #9073

Closed
wants to merge 9 commits into from

Conversation

kyoto7250
Copy link
Contributor

@kyoto7250 kyoto7250 commented Jun 30, 2022

close #8982

This PR adds [unnecessary_reserve] lint.

note: This lint targets next stable versions (1.62), so we cannot merge it now.


changelog: add [unnecessary_reserve] lint
#9073

@rust-highfive
Copy link

r? @flip1995

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Jun 30, 2022
@kyoto7250 kyoto7250 force-pushed the issue_8982 branch 2 times, most recently from 1691b1d to fa604eb Compare June 30, 2022 14:45
clippy_lints/src/unnecessary_reserve.rs Outdated Show resolved Hide resolved
clippy_lints/src/unnecessary_reserve.rs Outdated Show resolved Hide resolved
clippy_lints/src/unnecessary_reserve.rs Outdated Show resolved Hide resolved
cx,
UNNECESSARY_RESERVE,
next_stmt_span,
"this `reserve` no longer makes sense in rustc version >= 1.62",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This message is shown on the extend call.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had missed it, Thanks!

&& let Some(next_stmt_span) = check_extend_method(cx, block, idx, struct_calling_on)
&& !next_stmt_span.from_expansion()
{
span_lint(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't this have a MaybeIncorrect suggestion?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fixed in 2c4bca2

&& let Some(next_stmt_span) = check_extend_method(cx, block, idx, struct_calling_on)
&& !next_stmt_span.from_expansion()
{
span_lint(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be nice to have a note here, so both the reserve and extend calls are visible.

@kyoto7250
Copy link
Contributor Author

@Serial-ATA

Thanks for your review 👍🏻
I will check and fix.

@bors
Copy link
Contributor

bors commented Jul 3, 2022

☔ The latest upstream changes (presumably #9105) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Jul 6, 2022

☔ The latest upstream changes (presumably #9099) made this pull request unmergeable. Please resolve the merge conflicts.

@kyoto7250 kyoto7250 marked this pull request as ready for review July 10, 2022 14:08
@bors
Copy link
Contributor

bors commented Jul 15, 2022

☔ The latest upstream changes (presumably #9103) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Jul 25, 2022

☔ The latest upstream changes (presumably #9243) made this pull request unmergeable. Please resolve the merge conflicts.

clippy_lints/src/unnecessary_reserve.rs Outdated Show resolved Hide resolved
clippy_lints/src/unnecessary_reserve.rs Outdated Show resolved Hide resolved
clippy_lints/src/unnecessary_reserve.rs Outdated Show resolved Hide resolved
@bors
Copy link
Contributor

bors commented Aug 2, 2022

☔ The latest upstream changes (presumably #9264) made this pull request unmergeable. Please resolve the merge conflicts.

kyoto7250 and others added 9 commits August 14, 2022 14:07
Co-authored-by: Alex <69764315+Serial-ATA@users.noreply.github.com>
Co-authored-by: Alex <69764315+Serial-ATA@users.noreply.github.com>
Co-authored-by: Alex <69764315+Serial-ATA@users.noreply.github.com>
Co-authored-by: Alex <69764315+Serial-ATA@users.noreply.github.com>
Co-authored-by: Alex <69764315+Serial-ATA@users.noreply.github.com>
Co-authored-by: Alex <69764315+Serial-ATA@users.noreply.github.com>
@bors
Copy link
Contributor

bors commented Aug 18, 2022

☔ The latest upstream changes (presumably #9136) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Member

@flip1995 flip1995 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this lint would be better placed in the methods module, since you check for a specific method call. That way you also don't have to implement all of the method matching logic.

Comment on lines +13 to +16
/// This lint checks for a call to `reserve` before `extend` on a `Vec` or `VecDeque`.
/// ### Why is this bad?
/// Since Rust 1.62, `extend` implicitly calls `reserve`
/// ### Example
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: readability

Suggested change
/// This lint checks for a call to `reserve` before `extend` on a `Vec` or `VecDeque`.
/// ### Why is this bad?
/// Since Rust 1.62, `extend` implicitly calls `reserve`
/// ### Example
/// This lint checks for a call to `reserve` before `extend` on a `Vec` or `VecDeque`.
///
/// ### Why is this bad?
/// Since Rust 1.62, `extend` implicitly calls `reserve`
///
/// ### Example

@@ -12,7 +12,7 @@ macro_rules! msrv_aliases {

// names may refer to stabilized feature flags or library items
msrv_aliases! {
1,62,0 { BOOL_THEN_SOME }
1,62,0 { BOOL_THEN_SOME, UNNECESSARY_RESERVE }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be named after the feature that was introduced rather than after the lint.

if let StmtKind::Semi(semi_expr) = stmt.kind
&& let ExprKind::MethodCall(_, [struct_calling_on, _], _) = semi_expr.kind
&& let Some(expr_def_id) = cx.typeck_results().type_dependent_def_id(semi_expr.hir_id)
&& (match_def_path(cx, expr_def_id, &paths::VEC_RESERVE) ||
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These new paths might not be necessary, if you compare the method name and then check the type of the receiver (struct_calling_on). The type of the receiver can be checked with is_ty_diagnostic_item(..., sym::Vec) and similar for VecDeque.

EDIT: Just saw, that you're already doing this in acceptable_type. So this path comparison is not really necessary. Just compare the method name.

clippy_lints/src/unnecessary_reserve.rs Show resolved Hide resolved
struct_expr: &rustc_hir::Expr<'_>,
) -> Option<rustc_span::Span> {
let mut read_found = false;
let next_stmt_span;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not pre-declare this, but rather use a more Rust like style below with

let next_stmt_span = if idx == block.stmts.len() - 1 {

}

#[must_use]
fn equal_ident(left: &rustc_hir::Expr<'_>, right: &rustc_hir::Expr<'_>) -> bool {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure, you can use our SpanlessEq utility for this.

Comment on lines +19 to +20
vec.reserve(1);
vec.extend([1]);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unsure if this should lint. I think this should only lint for

vec.reserve(expr.len());
vec.extend(expr);

where expr is just any arbitrary expression where len is called on in the reserve call and then used in the extend call. To check if the expression is the same, you can use SpanlessEq.

Or am I missing something?

Comment on lines +7 to +13
fn main() {
vec_reserve();
vec_deque_reserve();
hash_map_reserve();
msrv_1_62();
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: This should be at the end of the test file.

--> $DIR/unnecessary_reserve.rs:29:9
|
LL | vec.reserve(1);
| -------------- help: remove this line
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the span of the suggestion is wrong? Shouldn't it include the ; as well?

impl_lint_pass!(UnnecessaryReserve => [UNNECESSARY_RESERVE]);

impl<'tcx> LateLintPass<'tcx> for UnnecessaryReserve {
fn check_block(&mut self, cx: &LateContext<'tcx>, block: &Block<'tcx>) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure you don't have to check the whole block, but rather just the expression and if you find a reserve call, you can use get_enclosing_block, find the next expression/statement in the block and then just check that. I even doubt that you need a visitor for this.

@flip1995 flip1995 added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Aug 19, 2022
@xFrednet
Copy link
Member

Hey @kyoto7250 this is a ping from triage. Are there any updates on this PR? If you're stuck or need assistance, you're always welcome to reach out.

@kyoto7250
Copy link
Contributor Author

kyoto7250 commented Dec 16, 2022

@xFrednet
Sorry, currently I am too busy, so I cannot maintain this PR.
You may close this PR.

I want to re-open and do when I have more time.

@xFrednet
Copy link
Member

That's totally fine, thank you for the swift response and work, you already put into this!

@xFrednet xFrednet closed this Dec 17, 2022
@xFrednet xFrednet added S-inactive-closed Status: Closed due to inactivity and removed S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Dec 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-inactive-closed Status: Closed due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unnecessary Vec/VecDeque reserve lint
6 participants