Create all_equal_linter()

[Bisaloo]

Fix #2610

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.27%. Comparing base (ab329d8) to head (27cfd18).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2885   +/-   ##
=======================================
  Coverage   99.27%   99.27%           
=======================================
  Files         128      129    +1     
  Lines        7160     7177   +17     
=======================================
+ Hits         7108     7125   +17     
  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.

[MichaelChirico]

Shall we cover attr.all.equal too?

Either TRUE (NULL for attr.all.equal) or a vector of mode "character" describing the differences between target and current.

[Bisaloo]

I would say probably not. Since it returns NULL in the case of no differences, I would expect that it's already wrapped in is.null() and thus safe.

[MichaelChirico]

I wouldn't advertise this:

• isTRUE() is specifically designed to overcome shortcomings of identical(x, TRUE)
• I guess it's rare to do something like identical(all.equal(x, y), "Mean relative difference ...")

There may be some advantages to identical() but I don't think we need to cite them here, too detailed

[Bisaloo]

I think it became clearer later in the review but the idea was not to recommend wrapping all.equal() in identical(). I agree isTRUE() is a better solution here.

But I have seen the following thought process happen:

x <- letters

if (x == letters) {
  message("success")
}
#> Error in if (x == letters) {: the condition has length > 1

# Oh no, it doesn't work. How can I compare that all elements of x are equal to
# elements of letters

if (all.equal(x, letters)) {
  message("success")
}
#> success

^{Created on 2025-07-23 with reprex v2.1.1}

In reality, in these cases, the author was really looking for identical(), not all.equal().

I have the feeling this is what happened in most cases where all.equal() compares character vectors (see https://github.com/search?q=org%3Acran%20%2Fall%5C.equal%5C(names%5C(%2F&type=code). This might be a good new case for this linter in a follow up PR.

[Bisaloo]

Would you have a suggestion to phrase this idea more clearly?

[MichaelChirico]

I would just use isTRUE(), I think that's the safest drop-in alternative

[MichaelChirico]

I see, this corresponds to the clarified note in the lint_message... maybe just add a comment above this example with the same clarification about not needing tolerance?

[MichaelChirico]

BTW stopifnot() has some built-in logic for handling all.equal() checks, c.f.

stopifnot(all.equal(1, 1.001))
# Error: 1 and 1.001 are not equal:
#   Mean relative difference: 0.001

I might actually lint this code while we're at it:

stopifnot(isTRUE(all.equal(x, y)))

Since it gives a worse error:

stopifnot(isTRUE(all.equal(1, 1.001)))
# Error: isTRUE(all.equal(1, 1.001)) is not TRUE

Some hits:

https://github.com/search?q=lang%3AR%20%2Fstopifnot%5C(%2F%20%2FisTRUE%5C(all%5C.equal%5C(%2F&type=code

We can do that as a follow-up if you'd like; in this PR at least I'd want to have some mention of stopifnot().

[MichaelChirico]

We might as well test isFALSE(all.equal()) here too, it gets some usage:

https://github.com/search?q=lang%3AR+%2FisFALSE%5C%28all%5C.equal%5C%28%2F&type=code

[Bisaloo]

Yes, isFALSE(all.equal()) is definitely wrong since it'll always return FALSE. I wonder if that'd fit better under a istrue_linter() that check cases where authors wanted !isTRUE() rather than isFALSE().

[Bisaloo]

Similarly for stopifnot(), great catch but I wonder if it should live here or in stopifnot_all_linter() 🤔

[Bisaloo]

If we don't end up covering more cases in this linter, that'd be a good candidate for make_lint_from_function_xpath().