Skip to content
New issue

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

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

Already on GitHub? # to your account

Make ARG002 compatible with EM101 when raising NotImplementedError #13714

Merged
merged 11 commits into from
Oct 18, 2024

Conversation

Watercycle
Copy link
Contributor

@Watercycle Watercycle commented Oct 11, 2024

Summary

This pull request resolves some rule thrashing identified in #12427 by allowing for unused arguments when using NotImplementedError with a variable per this comment.

Note

This feels a little heavy-handed / edge-case-prone. So, to be clear, I'm happy to scrap this code and just update the docs to communicate that abstractmethod and friends should be used in this scenario (or similar). Just let me know what you'd like done!

fixes: #12427

Test Plan

I added a test-case to the existing ARG.py file and ran...

cargo run -p ruff -- check crates/ruff_linter/resources/test/fixtures/flake8_unused_arguments/ARG.py --no-cache --preview --select ARG002

Copy link
Contributor

github-actions bot commented Oct 11, 2024

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Copy link
Member

@MichaReiser MichaReiser left a comment

Choose a reason for hiding this comment

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

This looks good to me. Would you mind adding a test string with an f-string message?


let ast::Expr::Call(ast::ExprCall {
func, arguments, ..
}) = exception.as_ref()
Copy link
Member

Choose a reason for hiding this comment

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

Nit:

Suggested change
}) = exception.as_ref()
}) = &**exception

Copy link
Contributor Author

@Watercycle Watercycle Oct 16, 2024

Choose a reason for hiding this comment

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

I see mixed usages of &** and as_ref throughout the code base. Out of curiosity, when is one used over the other? The general heuristic I've seen is * and & are recommended for simple stuff; and, once you start de-referencing and re-borrowing, that as_ref is recommended if just to avoid needing to think about whatever container the value* is in.

Copy link
Member

Choose a reason for hiding this comment

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

We used to use as_ref but started to prefer dereferencing (except for Option where you still need as_ref and as_deref) because it's possible that as_ref becomes ambiguous if a new AsRef implementation is added to a type. For example, String has many as_ref methods:

  = note: multiple `impl`s satisfying `String: AsRef<_>` found in the following crates: `alloc`, `std`:
          - impl AsRef<OsStr> for String;
          - impl AsRef<Path> for String;
          - impl AsRef<[u8]> for String;
          - impl AsRef<str> for String;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh interesting, that makes sense! Thank you!

@MichaReiser MichaReiser added the rule Implementing or modifying a lint rule label Oct 14, 2024
@dhruvmanila dhruvmanila self-assigned this Oct 18, 2024
Copy link
Member

@dhruvmanila dhruvmanila left a comment

Choose a reason for hiding this comment

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

Thanks for the PR!

I made a few final changes:

  • We should match the assignment target and argument node exactly. Previously, if either of them isn't a name node, the function would return true.
  • Added some more test cases where ARG002 should be raised

@dhruvmanila
Copy link
Member

Going to wait for ecosystem checks and then merge.

@dhruvmanila dhruvmanila changed the title Make ARG002 compatible with EM101 (no unused args vs no raw exception message) Make ARG002 compatible with EM101 when raising NotImplementedError Oct 18, 2024
@dhruvmanila dhruvmanila enabled auto-merge (squash) October 18, 2024 06:30
@dhruvmanila dhruvmanila added bug Something isn't working and removed rule Implementing or modifying a lint rule labels Oct 18, 2024
@dhruvmanila dhruvmanila enabled auto-merge (squash) October 18, 2024 06:41
@dhruvmanila dhruvmanila merged commit f80528f into astral-sh:main Oct 18, 2024
19 checks passed
@Watercycle Watercycle deleted the arg002-em101-compatibility branch October 20, 2024 06:03
@Watercycle
Copy link
Contributor Author

I made a few final changes:

Thank you for fixing it up! I noticed the snapshot test didn't get updated after committing and thought "this can be Sunday's problem" 😅

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

When raising NotImplementedError , ARG002 and EM101 are incompatible.
3 participants