Start a fuzzing suite to test for consistency of lints

[MichaelChirico]

Part of #2191. Progress on #2737. Continuation of #2190.

For this initial PR, I've only added a rule about FUNCTION (function(...) { ... }) and OP-LAMBDA (\(...) { ... }) equivalency.

Hopefully my approach here is extensible for other rules (I tried for that). My plan is for this to only run on main, though it's certainly fast enough to run on every PR.

The upshot is, it smoked out three linters with inconsistencies already!

[MichaelChirico]

@DavisVaughan / @lionel-, I'm curious if any of your recent work on {air}/{treesitter.r} & friends could be re-used here.

The idea is we want to make random injections/edits to the R AST (and then do stuff), my approach here felt quite manual/labor-intensive.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.64%. Comparing base (c315baf) to head (523c218).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2818   +/-   ##
=======================================
  Coverage   99.64%   99.64%           
=======================================
  Files         126      126           
  Lines        6960     6961    +1     
=======================================
+ Hits         6935     6936    +1     
  Misses         25       25           

☔ 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.

[DavisVaughan]

The closest thing I can think of is parser_reparse() in {treesitter}
https://davisvaughan.github.io/r-tree-sitter/reference/parser-parse.html

It performs an incremental reparse and hands you back a new tree with the edit you made. It's quite verbose in terms of what you have to provide (bytes and points) but this is a tree-sitter limitation (and I'm sure they had some reason for it).

Note that text here in parser_reparse() is the entire original source document with a single contiguous edit already applied to it (it's not the incremental bit of text)

For Air, I don't think Rowan trees are really intended to be edited. At least, there doesn't seem to be any easy to use API for that (and plus Rowan isn't exposed in any R package right now anyways)

[MichaelChirico]

Interesting, yea the incremental re-parse is very neat, but more useful in an IDE setting. Here the latency of re-parse is not much concern as the edits are only a tiny fraction of the action run time.

For Air, I don't think Rowan trees are really intended to be edited. At least, there doesn't seem to be any easy to use API for that (and plus Rowan isn't exposed in any R package right now anyways)

Hmm, I guess in my mind something like {styler} / {air} is well-suited here if it exposes a friendly API for transformers, i.e. instead of the usual helpful rule like 'make this line <80 characters', we have a more adversarial rule like "add comments in random but syntactically valid places". I not be understanding where in the stack behind the format-on-save tool such an analog would sit.

[lionel-]

For Air, I don't think Rowan trees are really intended to be edited. At least, there doesn't seem to be any easy to use API for that (and plus Rowan isn't exposed in any R package right now anyways)

I may be misunderstanding what you mean but AFAIK the red trees in Rowan are modifiable. I believe this is used for refactorings in rust-analyzer.