[pull] master from google:master #255
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
…. This could only happen in code paths involving the just-added ImmutableSetMultimap.orderValuesBy.expectedValuesPerKey. RELNOTES=n/a PiperOrigin-RevId: 660086928
…al tables in current. PiperOrigin-RevId: 660087654
RELNOTES=n/a PiperOrigin-RevId: 661405546
RELNOTES=n/a PiperOrigin-RevId: 662078968
PiperOrigin-RevId: 662120655
…ould overflow. RELNOTES=n/a PiperOrigin-RevId: 662127972
This is a followup to cl/655152611. As noted in the description of that CL, I didn't migrate the _implementations_ because of GWT+J2CL constraints. Those constraints bind very few users, so I don't think we need to acknowledge them in the Javadoc. (If we start to think that an implementation migration might actually pay off in performance improvements, we could arrange for it by setting up GWT+J2CL supersource.) Also, note that the methods are [available under Android even without opting in to library desugaring](https://r8.googlesource.com/r8/+/5c88be7bffa502cddc989f80beffc0dd5402a057/src/main/java/com/android/tools/r8/ir/desugar/BackportedMethodRewriter.java#961). RELNOTES=n/a PiperOrigin-RevId: 662217380
…orthcoming version of our nullness checker. The headliner in this CL is the addition of missing annotations in `Immutable*.Builder` (though the annotations don't reveal any danger of NPE). This CL also works around a type-inference problem in `Multisets`. Finally, it has a simplification in `SortedLists` that used to work around a problem but that is no longer necessary. Still, a simplification is a simplification, so I've kept it as part of the CL anyway. RELNOTES=n/a PiperOrigin-RevId: 663810873
RELNOTES=n/a PiperOrigin-RevId: 663837851
Bumps the github-actions group with 2 updates: [actions/upload-artifact](https://github.com/actions/upload-artifact) and [github/codeql-action](https://github.com/github/codeql-action). Updates `actions/upload-artifact` from 4.3.5 to 4.3.6 - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@89ef406...834a144) Updates `github/codeql-action` from 3.25.15 to 3.26.0 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@afb54ba...eb055d7) Fixes #7361 RELNOTES=n/a PiperOrigin-RevId: 663874856
RELNOTES=n/a PiperOrigin-RevId: 664836848
Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action). Updates `github/codeql-action` from 3.26.0 to 3.26.2 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@eb055d7...429e197) Fixes #7366 RELNOTES=n/a PiperOrigin-RevId: 664849357
(followup to cl/660005124) RELNOTES=n/a PiperOrigin-RevId: 664961621
…call them at all). They already had changed to always throw an exception back in JDK 20 (so we have been skipping the test from that version on), and they're removed entirely in JDK 23. We want to still be able to compile against JDK 23, but we might as well keep the tests functional under the older versions that we still test with. PiperOrigin-RevId: 666474799
… arrays contain too many elements. Fixes #7376 Fixes #3303 This change comes from @perceptron8, who generalized the earlier PR by @ineuwirth. RELNOTES=n/a PiperOrigin-RevId: 668024782
RELNOTES=n/a PiperOrigin-RevId: 668055504
As of cl/655647768, we always build with JDK 22. RELNOTES=n/a PiperOrigin-RevId: 668969633
Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action). Updates `github/codeql-action` from 3.26.2 to 3.26.5 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@429e197...2c779ab) Fixes #7374 RELNOTES=n/a PiperOrigin-RevId: 669378818
Bumps the github-actions group with 2 updates: [actions/upload-artifact](https://github.com/actions/upload-artifact) and [github/codeql-action](https://github.com/github/codeql-action). Updates `actions/upload-artifact` from 4.3.6 to 4.4.0 - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@834a144...5076954) Updates `github/codeql-action` from 3.26.5 to 3.26.6 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@2c779ab...4dd1613) Fixes #7386 RELNOTES=n/a PiperOrigin-RevId: 671039923
github-actions group Bumps the github-actions group with 1 update: [actions/setup-java](https://github.com/actions/setup-java). Updates `actions/setup-java` from 4.2.2 to 4.3.0 - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](actions/setup-java@6a0805f...2dfa201) Fixes #7389 RELNOTES=n/a PiperOrigin-RevId: 672578189
Our nullness checking has seen `@NonNull` annotations in the JDK since cl/648064454. RELNOTES=n/a PiperOrigin-RevId: 672970833
Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action). Updates `github/codeql-action` from 3.26.6 to 3.26.7 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@4dd1613...8214744) Fixes #7393 RELNOTES=n/a PiperOrigin-RevId: 675248105
...by actually using our own homegrown versions that avoid reflection. (followup to cl/563137030 + cl/570474348) Also, suppress/address a few other warnings. And incidentally, largely rewrite `ThrowablesTest`. We're allowed to learn a thing or two about writing tests over the course of 17+ years :) (I'd specifically highlight the old `testPropagateIfInstanceOf_uncheckedThrown` test, which has been replaced with the similarly `testPropagateIfInstanceOf_unchecked`: It might have appeared to have been a test that `propagateIfInstanceOf` would throw the given unchecked exception, but in fact what it actually shows is that _`propagate`_ does so. `propagateIfInstanceOf` does not and should not. Additionally, I think that my new `testPropagateIfPossible_twoDeclared_secondSame` covers a case that wasn't covered before.) Future work: - Perform this migration for our other packages. - Generalize AssertThrowsMultipleStatements to cover our `assertThrows` methods. - Maybe migrate non-GWT/J2CL/J2KT calls of `assertThrows` to our methods, too. This migration should save us from warnings from the recent changes to the EmptyCatch check in cl/674409794. The approach used in this change (of declaring both `ThrowingRunnable` and `ThrowingSupplier` overloads of `assertThrows`) saves us from needing to update our CheckReturnValue enforcement to recognize the new `assertThrows` variants. Note also that it lets us provide a slightly better failure message, as discussed back in junit-team/junit5#1394. RELNOTES=n/a PiperOrigin-RevId: 675634517
Bumps the github-actions group with 1 update: [github/codeql-action](https://github.com/github/codeql-action). Updates `github/codeql-action` from 3.26.7 to 3.26.8 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@8214744...294a9d9) Fixes #7398 RELNOTES=n/a PiperOrigin-RevId: 677824554
While that artifact contains no runtime-retention annotations, it does contain class-retention annotations (which could drive a runtime bytecode-rewriting agent). And, more practically, the Android Gradle Plugin has started reporting errors for `compileOnly` dependencies. Fixes #7397 Relevant to firebase/firebase-android-sdk#6232 and androidx/media#1700 RELNOTES=Added `j2objc-annotations` to the Gradle runtime classpath to avoid [an Android Gradle Plugin error](#7397). PiperOrigin-RevId: 677842769
…terable. RELNOTES=n/a PiperOrigin-RevId: 678224792
RELNOTES=n/a PiperOrigin-RevId: 678330548
RELNOTES=n/a PiperOrigin-RevId: 725740741
This prepares us to potentially add `java.io.Serial` to them at some point. Mostly, this CL adds `@GwtIncompatible` and/or `@J2ktIncompatible`. We have already needed the latter previously need for `serialVersionUID` fields in _inner_ classes, such as in cl/605627910. But now we may need them because `java.io.Serial` is not (currently) available under those environments. It's possible that I added the annotations in some cases in which they aren't necessary. I also left a comment in one class where I noticed a `serialVersionUID` field in one flavor but not the other. I ended up ignoring at least one other such class because that one was an implementation of an immutable collection, the implementations of which sometimes vary significantly between flavors. RELNOTES=n/a PiperOrigin-RevId: 725785821
RELNOTES=n/a PiperOrigin-RevId: 725859649
It's kind of amazing how much this improves readability in some cases. (Also, use `getOrDefault` in one place where we can, and suppress some suggestions to use it in places where we can't.) RELNOTES=n/a PiperOrigin-RevId: 725869779
It turns out that we'd changed our choice of `Queue` in `MultimapsTest` once previously in cl/16428259 _without updating the clever comment about it later in the file_ 😱 RELNOTES=n/a PiperOrigin-RevId: 726065051
RELNOTES=n/a PiperOrigin-RevId: 726090734
RELNOTES=n/a PiperOrigin-RevId: 726095812
This is the next piece of #7094, which is progress toward [modularization](#2970). I've modified this CL somewhat from the original version so that I can deploy a new version of `failureaccess` without needing to make any updates to `guava-parent` first. `failureaccess` does still use `guava-parent` (and I've bumped it to use the newest released version) for its configuration for Sonatype, Javadoc, etc. But I've inlined all the configuration that I need for the modularization. I did note a few differences from the original version: - This version includes `LICENSE` under `META-INF`, both in the main jar and in the sources jars. - This version uses a different configuration for Javadoc, I assume because my recent changes there didn't make it into 33.4.0. I also notice that _neither_ version contains `module-info.java` in its source jar. We could presumably fix that in the future if anyone is interested. (And while this isn't strictly related, I do notice that we could consider also releasing a modularized version of `listenablefuture` someday.) I have tested with: ``` $ JAVA_HOME=$HOME/.m2/jdks/jdk-17.0.13+11 ./mvnw clean install -Psonatype-oss-release -Dmaven.test.redirectTestOutputToFile=true -Dsurefire.printSummary=false -Drelease -f futures/failureaccess ``` (Some of those flags aren't necessary, but I found it easiest to copy what our release script does for "normal" releases.) I would use `deploy` instead of `install` for the real thing. Relates-To: elide-dev/jpms#1 Signed-off-by: Sam Gammon <[email protected]> RELNOTES=Changed the `failureaccess` jar to be a modular jar. PiperOrigin-RevId: 726100871
[`@Serial`](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/Serial.html) was added in Java 14, but it has only `SOURCE` retention, so it requires Java 14+ only [at _build_ time](#6549). Guava continues to support Java 8 at runtime, and it already has required a higher version (though perhaps only Java 9+?) to build. Still, if this change causes people trouble, it is easy enough for us to include `@Serial` only in our Google-internal source or even to back out the change entirely. (Part of the purpose of this change is to identify any such trouble before we add any features that require newer versions of Java to build "for real.") Alternatively, if this change goes well, we can consider using `@Serial` on _all_ eligible APIs. RELNOTES=n/a PiperOrigin-RevId: 726154745
…ings. RELNOTES=n/a PiperOrigin-RevId: 726167935
…nings. RELNOTES=n/a PiperOrigin-RevId: 726172349
…quality warnings. RELNOTES=n/a PiperOrigin-RevId: 726178790
...plus one https://errorprone.info/bugpattern/UnusedMethod warning. RELNOTES=n/a PiperOrigin-RevId: 726481058
They [break our JDiff setup](https://github.com/google/guava/actions/runs/13294400054/job/37123745397). (followup to cl/726154745) I should [finish setting up japicmp](google/error-prone#4311 (comment)), but for now, I want to unbreak publishing documentation for releases and snapshots. (Some of the code formatting ends up a little odd because of how I'm stripping the annotations. We should be able to live with it until I can put the annotations back—or until we discover that they're causing problems _internally_ and need to withdraw them entirely :)) RELNOTES=n/a PiperOrigin-RevId: 726521329
They are the product of cl/726095812 and... cl/133039225 + cl/137220845 + cl/139396264, oops! RELNOTES=n/a PiperOrigin-RevId: 726615521
RELNOTES=n/a PiperOrigin-RevId: 726922078
RELNOTES=n/a PiperOrigin-RevId: 728204140
One is from cl/725859649 (I _thought_ I had tested that change with nullness checking on), and the other is from [a change to the annotations for `Map.replace` used by Android](jspecify/jdk#118). (I think that the latter change should actually be leading to _more_ errors in our _other_ implementations of the 3-arg `Map.replace`, like in `Maps` and `Synchronized`. The lack of errors is probably a bug in the checker.) RELNOTES=n/a PiperOrigin-RevId: 728229469
There is nothing wrong with it, and we will add it in version 33.5.0. I'm removing it merely so that we can release a [module-system-friendly](#2970) version of Guava as a _patch_ release, rather than as a _minor_ release. (The `MediaType` change is the only addition we've made since 33.4.0.) By doing so, we reduce the pressure on users to upgrade immediately, since dependencies can't come to depend on any new APIs. That gives users a little more time to sort out any issues that might arise from our new `module-info`. RELNOTES=n/a PiperOrigin-RevId: 728267849
RELNOTES=n/a PiperOrigin-RevId: 728705777
… to `MoreExecutors.shutdownAndAwaitTermination`. RELNOTES=n/a PiperOrigin-RevId: 728722633
RELNOTES=n/a PiperOrigin-RevId: 728791732
Workaround is no longer required. PiperOrigin-RevId: 729083405
In pre-[modularization](#2970) cl/725625326, I had pledged not to bikeshed over this. But it turns out that the number matters to some part of our JDiff pipeline, which has been broken since that CL. (Then I broke it _even more_ by introducing usages of `java.io.Serial` (cl/726154745), which I've since rolled back externally (cl/726521329).) We still really should [finish setting up japicmp](google/error-prone#4311 (comment)) to replace JDiff, but again, I just want to unbreak publishing documentation for releases and snapshots. (I will still view this as a _small_ bit of evidence that biggest version number is best version number for snapshot purposes :)) RELNOTES=n/a PiperOrigin-RevId: 729117340
…he classes look slightly more similar to one another. RELNOTES=n/a PiperOrigin-RevId: 729152015
PiperOrigin-RevId: 729184487
…g it for more environments. That includes J2KT and [GWT/J2CL](#2934). Changes include: - Suppress nullness at smaller scopes, fixing errors that were hidden by the old, broad suppression. - Remove `synchronized` from an override of `fillInStackTrace`. J2KT doesn't like `synchronized` except on very specific types, and we don't need it. - Introduce `rethrowIfErrorOtherThanStackOverflow` and `interruptCurrentThread`, `Platform` methods that will require different implementations for J2KT and J2CL/GWT. - Introduce helper methods like `casListeners(expect, update)` for `AtomicHelper` operations. These reduce verbosity relative to `ATOMIC_HELPER.casListeners(this, expect, update)`. They also prepare for `AbstractFuture` implementations that don't use `AtomicHelper`. - Introduce `notInstanceOfSetFuture`. This is arguably nicer than `!(localValue instanceof SetFuture)`, but the real purpose is to prepare for when code in a different file needs to check `instance SetFuture`. (I could be convinced that I should just make `SetFuture` package-private instead, even though no one outside the file should use it for anything but an `instanceof` check.) - Mysteriously move things around, increase visibility of members, and introduce and sometimes use accessors. This is to prepare for when some of the code will be moving to a separate file so that the remainder of `AbstractFuture` can be wholly shared across different platforms. - Fix a few typos in comments. Also, rename `SetFuture`. This isn't directly related, but now is as good a time as any to do it. Additional bonus: This CL probably makes [the logging at the "end" of `AbstractFuture` static initialization](https://github.com/google/guava/blob/7ec362ec68b630363231d5292cd6b2577c710be6/guava/src/com/google/common/util/concurrent/AbstractFuture.java#L210) have a better chance of actually working in the hypothetical situation that a logger uses `AbstractFuture`: Currently, `AbstractFuture` performs some further initialization _after_ that logging (such as the initialization of `NULL`). Now, it performs all that initialization before the `static` block that might log. RELNOTES=n/a PiperOrigin-RevId: 729313044
…om GWT/J2CL. This CL introduces a superclass, `AbstractFutureState`, following the pattern of [`AggregateFutureState`](https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/AggregateFutureState.java). That superclass contains platform-specific operations. Fixes #2934 RELNOTES=n/a PiperOrigin-RevId: 729328833
…). RELNOTES=n/a PiperOrigin-RevId: 729532679
- mostly https://errorprone.info/bugpattern/UnnecessaryParentheses (by removing the parentheses) - in `HostAndPort`, https://errorprone.info/bugpattern/UnusedException (by using `tryParse` instead of a `try`-`catch` approach, conveniently also getting the behavior we want for `+` and for non-ASCII digits for free) - in `IntMath`, https://errorprone.info/bugpattern/NonFinalStaticField (by making it `final` :)) RELNOTES=n/a PiperOrigin-RevId: 729533506
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.1)
Can you help keep this open source service alive? 💖 Please sponsor : )