-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Conversation
r? @flip1995 (rust-highfive has picked a reviewer for you, use r? to override) |
1691b1d
to
fa604eb
Compare
cx, | ||
UNNECESSARY_RESERVE, | ||
next_stmt_span, | ||
"this `reserve` no longer makes sense in rustc version >= 1.62", |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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.
Thanks for your review 👍🏻 |
☔ The latest upstream changes (presumably #9105) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #9099) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #9103) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #9243) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #9264) made this pull request unmergeable. Please resolve the merge conflicts. |
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>
☔ The latest upstream changes (presumably #9136) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this 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.
/// 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: readability
/// 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 } |
There was a problem hiding this comment.
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) || |
There was a problem hiding this comment.
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.
struct_expr: &rustc_hir::Expr<'_>, | ||
) -> Option<rustc_span::Span> { | ||
let mut read_found = false; | ||
let next_stmt_span; |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
vec.reserve(1); | ||
vec.extend([1]); |
There was a problem hiding this comment.
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?
fn main() { | ||
vec_reserve(); | ||
vec_deque_reserve(); | ||
hash_map_reserve(); | ||
msrv_1_62(); | ||
} | ||
|
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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>) { |
There was a problem hiding this comment.
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.
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. |
@xFrednet I want to re-open and do when I have more time. |
That's totally fine, thank you for the swift response and work, you already put into this! |
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