Skip to content

feat: argument to disable linting of ( for auto-printing #2919

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

TimTaylor
Copy link

Adds an argument to implicit_assignment_linter to disable linting of ( for auto-printing.
closes #2916

@@ -48,6 +48,7 @@
* `object_usage_linter()` lints missing packages that may cause false positives (#2872, @AshesITR)
* New argument `include_s4_slots` for the `xml_find_function_calls()` entry in the `get_source_expressions()` to govern whether calls of the form `s4Obj@fun()` are included in the result (#2820, @MichaelChirico).
* `sprintf_linter()` lints `sprintf()` and `gettextf()` calls when a constant string is passed to `fmt` (#2894, @Bisaloo).
* `implicit_assignment_linter()` gains argument `allow_print` to disable lints for the use of `(` for auto-printing (#2919, @TimTaylor).
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think allow_implicit_print may be better, WDYT? My only hesitation is doubling "implicit" in the linter & argument names...

Copy link
Author

Choose a reason for hiding this comment

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

allow_bracket_print?

I'm already wary of implicit as a description as it already doesn't reflect how I think of my usage of this lint ... basically "stop people accidentally using <- in function calls". I'd prefer not to use the term more if possible.

@@ -116,6 +130,9 @@ implicit_assignment_linter <- function(except = c("bquote", "expression", "expr"
bad_expr <- xml_find_all(xml, xpath)

print_only <- !is.na(xml_find_first(bad_expr, "parent::expr[parent::exprlist and *[1][self::OP-LEFT-PAREN]]"))
if (allow_print) {
bad_expr <- bad_expr[!print_only]
Copy link
Collaborator

Choose a reason for hiding this comment

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

This works, I think it will be ideal to work this in to the up-front XPath logic, rather than including those hits in the search only to drop them.

Have a try and if you get stuck we can mark it as a follow-up issue.

Copy link
Author

@TimTaylor TimTaylor Aug 4, 2025

Choose a reason for hiding this comment

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

I thought that initially but then I realised you need to do the print_only for the error message anyway so this seemed to be the most KISS approach. WDY?

Copy link

codecov bot commented Aug 4, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.28%. Comparing base (1939058) to head (f136901).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2919   +/-   ##
=======================================
  Coverage   99.28%   99.28%           
=======================================
  Files         129      129           
  Lines        7266     7269    +3     
=======================================
+ Hits         7214     7217    +3     
  Misses         52       52           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@AshesITR
Copy link
Collaborator

Feels like a false positive to me - maybe we don't need an argument for this?

IINM this only removes top-level (x <- expr) lints, right?

@TimTaylor
Copy link
Author

TimTaylor commented Aug 11, 2025

Feels like a false positive to me - maybe we don't need an argument for this?

That would be great but the custom print error message seems like it was a deliberate choice to lint for.

IINM this only removes top-level (x <- expr) lints, right?

I believe so (but take my agreement with caution as I deliberately avoided delving in to the XPath logic due to the pre-existing custom error).

@AshesITR
Copy link
Collaborator

Oh, I see, sorry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

FR: add argument to disable linting of ( for auto-printing in implicit_assignment_linter
3 participants