Move symbol search into XPath in backport_linter

[MichaelChirico]

For #2338. This approach presents a bit of a conundrum as it seems the performance of the XPath algorithm degrades with the number of objects to search for:

(new: this PR; old: current main. 413: backport_linter("4.1.3"); 300: backport_linter("3.0.0"))

system.time(lint_all(f, old413))
#    user  system elapsed 
#  71.890   1.442  74.399 
system.time(lint_all(f, old300))
#    user  system elapsed 
#  70.846   1.036  72.075

system.time(lint_all(f, new413))
#    user  system elapsed 
#  65.206   0.711  66.198 
system.time(lint_all(f, new300))
#    user  system elapsed 
#  76.417   0.854  77.541 

i.e. we get about 10% improvement from the "easier" linter where there are fewer objects to look up, but 7% slowdown in the "harder" case with many objects to look up.

Not sure how to proceed. We may also want to check other linters that use a huge list of or checks & check alternate approaches.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (6d2b327) 99.13% compared to head (abaa734) 99.13%.

❗ Current head abaa734 differs from pull request most recent head 07ceea5. Consider uploading reports for the commit 07ceea5 to get more accurate results

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2365   +/-   ##
=======================================
  Coverage   99.13%   99.13%           
=======================================
  Files         124      124           
  Lines        5573     5573           
=======================================
  Hits         5525     5525           
  Misses         48       48           

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

[AshesITR]

Sounds like #2357 promises better performance than this approach in the long run.
Table until that PR is ready?

[MichaelChirico]

Sounds like #2357 promises better performance than this approach in the long run. Table until that PR is ready?

It will still need a //SYMBOL search, it may be cumbersome to have a linter using both the //SYMBOL_FUNCTION_CALL cache and a general XPath search.

Anyway it does seem like a broader issue, but my instinct is the affected cases will mostly be looking at //SYMBOL_FUNCTION_CALL, so makes sense to pause.

[MichaelChirico]

BTW, this at least partially seems related to our XPath1.0 restriction, it would be great to to have an XPath2.0+ backend but I don't see any R support for that. LLM turned up this C++ library XQilla though, a long-term project could be to write an R package wrapping this with the same/similar API as {xml2}.

[AshesITR]

NB: backport_linter() is converted in #2357 now.

[AshesITR]

This idea was implemented in #2357 as well now, so closing this PR.