Upgrade various dependencies

[liblit]

• Upgrades that only changed one line in gradle/libs.versions.toml:
  • Upgrade Ant
  • Upgrade Apache Commons IO
  • Upgrade GSON
  • Upgrade Guava
  • Upgrade JUnit
  • Upgrade SLF4J
  • Upgrade Spotless
  • Upgrade ktfmt (Kotlin formatter)
• Upgrades that changed one line in gradle/libs.versions.toml plus trivial (whitespace-only) changes elsewhere:
  • Update Google Java formatter
• Upgrades that changed one line in gradle/libs.versions.toml plus nontrivial changes elsewhere:
  • Upgrade Error Prone
  • Upgrade gradle-download-task

[msridhar]

This is a new ERROR-level check and usually it's best not to just suppress these. Did you look at the error message and conclude these were false positives? At the least we should add a comment. If we're not sure if the warnings are false positives, we should file an issue to look into them more, or maybe split out the Error Prone upgrade into a separate PR so we can upgrade and fix the issues at the same time.

[liblit]

Did you look at the error message and conclude these were false positives?

I did. In each case, the code in question is comparing the current count or size of something to a static final int limit, where that limit is set to Integer.MAX_VALUE. It appears that the intent is to have no limit by default, but also to make it easy to impose a limit by changing how the static final int is initialized. Here's a typical example:

Initialized field:

  private static final int MAX_SIZE = Integer.MAX_VALUE;

Latent limit check that is always true unless the initialization of MAX_SIZE is changed:

    if (size <= MAX_SIZE) {

I believe that these checks are correct when the limit is set to something below Integer.MAX_VALUE. I also believe that they intentionally become vacuous in the default case when the limit is Integer.MAX_VALUE. So the warnings are correct in that each check is either always true or always false, but that is by design.

[msridhar]

Thanks for the explanation! I wish we didn't have to suppress this error-level check, but I'm not sure there is a better way to do things. I guess we could set MAX_SIZE to Integer.MAX_VALUE - 1, which would make the check non-vacuous, or have a separate boolean variable to indicate whether a size limit is in place. But both of those options seem like overkill for this issue.

For now, could you add a short comment in each spot explaining the suppression?

[liblit]

44df486 improves our handling of these limit checks as follows:

• In DemandCastChecker, add the two ints in a way that avoids int overflow.
• In ImmutableStack, call a new helper function that centralizes the suppression and explains what's going on.

[github-actions]

Test Results

   451 files  ±0     451 suites  ±0   2h 52m 31s ⏱️ + 9m 16s
   730 tests ±0     713 ✔️ ±0  17 💤 ±0  0 ❌ ±0 
2 804 runs  ±0  2 734 ✔️ ±0  70 💤 ±0  0 ❌ ±0 

Results for commit 44df486. ± Comparison against base commit bb323c0.

♻️ This comment has been updated with latest results.

[msridhar]

Thanks for these updates!