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

Fix false positive for unit_arg lint #6601

Merged
merged 4 commits into from
Feb 25, 2021

Conversation

mdm
Copy link
Contributor

@mdm mdm commented Jan 17, 2021

Fixes #6447

To avoid false positives don't complain about unit args when they come from a path expression, e.g. a local variable.

Note: This is my first contribution to Clippy, so I might have messed up somewhere. Any feedback is welcome and I'm happy to work out any kinks.


changelog: Do not lint unit arguments when they come from a path expression.

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Manishearth (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Jan 17, 2021
@mdm
Copy link
Contributor Author

mdm commented Jan 17, 2021

I saw that the check for the size of the .stderr file failed. What would be the best way to resolve this?

@giraffate
Copy link
Contributor

How about splitting the test file into two?

@@ -955,7 +955,16 @@ impl<'tcx> LateLintPass<'tcx> for UnitArg {
.iter()
.filter(|arg| {
if is_unit(cx.typeck_results().expr_ty(arg)) && !is_unit_literal(arg) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you check the TypeFlags to see if the type was resolved from a variable? Maybe expr_ty(arg).needs_subst().

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, for the slow response. I missed your comment regarding the type flags. Checking needs_subst() does not seem to have the desired effect. The following example passes linting with my implemention, but running needs_subst() on the type for the argument of foo returns false:

    let arg = if true {
        1;
    };
    foo(arg);

I'm not familiar with the compiler internals. I looked at the definition of the various type flags, but did not really understand many of them. Do you have any suggestions?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thinking about it some more, I guess you meant type variables (as in the example in issue #6447). I will test that again later today.

Copy link
Contributor

@camsteffen camsteffen Feb 15, 2021

Choose a reason for hiding this comment

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

Yes I'm hoping we can detect type variables by looking at the TypeFlags which is readable through TypeFoldable (that's where needs_subst is). Another method in there that might be useful is has_projections which means a type with <X as Y>::Z. I am guessing a bit here as I don't completely understand when those different flags apply.

I'm afraid this might be even more complicated - we may have to detect "does the type variable reference a type that is defined outside of the impl block?".

Copy link
Contributor Author

@mdm mdm Feb 21, 2021

Choose a reason for hiding this comment

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

I think we need a different approach here. Using the example from issue #6447 I checked all the type flags and they are all false. So we might not get any help there.
One problem might be that the original lint looks at the type of the expression passed as the argument and not at the type of the argument from the function definition.
I'll investigate this further, but if you have additional ideas I would be grateful.

Copy link
Contributor

Choose a reason for hiding this comment

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

After thinking on this again, I think we should simply not lint if matches(arg.kind, ExprKind::Path). This will not lint if arg is a local variable.

It may be bad style to have a variable with unit as the type, but I think that should be linted upon declaration of the variable (not in this lint).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I changed my implementation to check for ExprKind::Path.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry to send you for a loop there.

@Manishearth
Copy link
Member

@camsteffen do you wanna handle review for this? I forgot this was in my queue.

@bors delegate=camsteffen

@bors
Copy link
Contributor

bors commented Feb 2, 2021

✌️ @camsteffen can now approve this pull request

@camsteffen
Copy link
Contributor

okay

@camsteffen
Copy link
Contributor

The fix looks good. Please add a test like the code in the bug report to give us better security for future enhancements.

@mdm
Copy link
Contributor Author

mdm commented Feb 24, 2021

I added the function baz as a simplified version of the code in the bug report. Should I add the exact test case from there instead?

@camsteffen
Copy link
Contributor

The test you added is good. Another test like the one in the bug report would be help us make sure we continue to handle that case properly in the future.

@camsteffen
Copy link
Contributor

Thanks! @bors r+

@bors
Copy link
Contributor

bors commented Feb 25, 2021

📌 Commit cbe6eec has been approved by camsteffen

@bors
Copy link
Contributor

bors commented Feb 25, 2021

⌛ Testing commit cbe6eec with merge d5223be...

@bors
Copy link
Contributor

bors commented Feb 25, 2021

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: camsteffen
Pushing d5223be to master...

@bors bors merged commit d5223be into rust-lang:master Feb 25, 2021
@bors bors mentioned this pull request Feb 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties
Projects
None yet
Development

Successfully merging this pull request may close these issues.

False positive for unit_arg when forwarding arguments
6 participants