[pull] master from google:master #247
Open
Conversation
This file contains hidden or 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
…ly stopped running it internally. RELNOTES=n/a PiperOrigin-RevId: 747441237
…he one in `Shorts`. (The annotations are from cl/746833146 and cl/746896418.) RELNOTES=n/a PiperOrigin-RevId: 747452059
RELNOTES=n/a PiperOrigin-RevId: 747502562
- Renamed `SetOperationsTest` to `SetViewTest` to make it easier to find. - Added `symmetricDifference` tests to the exhaustive test suite. - Refactored existing tests for `SetView`s to test independent behaviors separately. - Removed redundant tests from `SetsTest` so it's more obvious where to add new tests for `SetView`. RELNOTES=n/a PiperOrigin-RevId: 747522991
This has been unused since cl/138100073. RELNOTES=n/a PiperOrigin-RevId: 747539199
Compare cl/725785821 and cl/745110143. (I suppose we could imagine a future in which GWT, J2CL, and J2KT all _automatically_ strip members annotated with `@Serial`. We'd still need `@GwtIncompatible` and `@J2ktIncompatible` for "helpers" (i.e., classes, fields, and methods that aren't directly called by the Java serialization system), but we could at least omit those annotations from the `@Serial` members themselves.) RELNOTES=n/a PiperOrigin-RevId: 747924219
RELNOTES=n/a PiperOrigin-RevId: 748039878
RELNOTES=n/a PiperOrigin-RevId: 749844378
RELNOTES=n/a PiperOrigin-RevId: 750553810
…nterruptedException`. I added this as part of debugging an inexplicable flaky failure under Android Lollipop. The failure remains inexplicable, but I figured I might as well submit the new assertion. This assertion, by blocking on some `InterruptibleTask` output, conveniently makes the existing blocking in `join` obsolete. RELNOTES=n/a PiperOrigin-RevId: 752845298
RELNOTES=n/a PiperOrigin-RevId: 753681079
Bumps the github-actions group with 2 updates: [actions/setup-java](https://github.com/actions/setup-java) and [github/codeql-action](https://github.com/github/codeql-action). Updates `actions/setup-java` from 4.7.0 to 4.7.1 - [Release notes](https://github.com/actions/setup-java/releases) - [Commits](actions/setup-java@3a4f6e1...c5195ef) Updates `github/codeql-action` from 3.28.13 to 3.28.16 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](github/codeql-action@1b549b9...28deaed) Fixes #7793 RELNOTES=n/a PiperOrigin-RevId: 753682651
RELNOTES=Add {Int,Long}Math.saturatedAbs.
PiperOrigin-RevId: 755417595
RELNOTES=n/a PiperOrigin-RevId: 755465381
RELNOTES=n/a PiperOrigin-RevId: 755810613
It builds fine now, but if I start building `RangeTest` in its own target, separate from `LegacyComparable`, then it fails. This may be a result of flakiness in the Eclipse compiler, as we've seen before with GWT. RELNOTES=n/a PiperOrigin-RevId: 757868423
And address a few other warnings and a TODO along the way. RELNOTES=n/a PiperOrigin-RevId: 758274738
(like cl/728791732 but for our tests) RELNOTES=n/a PiperOrigin-RevId: 758309743
Also, in `IntMath.divide` and `LongMath.divide`, document equivalent standard operations for two `RoundingMode` choices, and add tests showing that those are indeed equivalent. RELNOTES=n/a PiperOrigin-RevId: 758435908
RELNOTES=N/A PiperOrigin-RevId: 758651251
RELNOTES=n/a PiperOrigin-RevId: 758791299
…/issue/KT-67447) in source instead of in internal build rules. By making the method `protected`, we no longer need to compile it as part of the same build target as its users. RELNOTES=n/a PiperOrigin-RevId: 758827643
…mal `collect` Android test target. As part of doing so, make `CollectorTester` available to external Android users. Internally, we'd been running them as part of a separate target from back in the days before we open-sourced our `Collector` APIs. Now that we've open-sourced those APIs, we can run their tests normally. RELNOTES=`testing`: Made `CollectorTester` available to Android users. PiperOrigin-RevId: 759308083
```
(192 bytes) ROOT CYCLE: <ComGoogleCommonCollectLinkedListMultimap_Node 0x600001a075c0> [64]
(64 bytes) next_ --> ROOT CYCLE: <ComGoogleCommonCollectLinkedListMultimap_Node 0x600001a07600> [64]
previous_ --> CYCLE BACK TO <ComGoogleCommonCollectLinkedListMultimap_Node 0x600001a075c0> [64]
```
RELNOTES=n/a
PiperOrigin-RevId: 759770348
…ropped this when importing the PR to convert `guava-jre` to a full module. Fixes #7813 RELNOTES=Restored `Automatic-Module-Name` for `guava-android`. I accidentally dropped this when importing the PR to convert `guava-jre` to a full module. PiperOrigin-RevId: 761093831
RELNOTES=n/a PiperOrigin-RevId: 761103343
RELNOTES=n/a PiperOrigin-RevId: 761490781
…se` later. I think I did this a while back for most of Guava (as it became possible [with minSdkVersion 19](https://developer.android.com/reference/java/lang/LinkageError#LinkageError(java.lang.String,%20java.lang.Throwable))), but I didn't get this one. RELNOTES=n/a PiperOrigin-RevId: 761990952
While there, rename a parameter in a test helper method to match the production parameter name. I admit that my new test is not necessarily the best of all possible tests: It detects the problem currently, but it wouldn't detect the problem if we were to change the prod code to decompose the `Duration` only [when it actually needs to block](https://github.com/google/guava/blob/e416f493d7f6790cae859aab1ddacb456469f614/guava/src/com/google/common/collect/Queues.java#L336). I kind of doubt we'd ever bother, though. RELNOTES=n/a PiperOrigin-RevId: 828005669
RELNOTES=n/a PiperOrigin-RevId: 828573832
Most `toString()` implementations mimic the code that could have produced the instance. Notably, `someCharMatcher.negate()` produces `someCharMatcher.toString() + ".negate()"`. But the `toString()` for `.and` and `.or` used a syntax that made it look as if these were static methods rather than instance ones. Also update a couple of tests that depend on the exact `toString()` output. RELNOTES=n/a PiperOrigin-RevId: 829198847
…6f4b did for `ImmutableSet`. Plus, expand the comment on `ImmutableSet` to acknowledge a second reason for the `unchecked` warning there. RELNOTES=n/a PiperOrigin-RevId: 829442016
…dundantNullCheck`](https://errorprone.info/bugpattern/RedundantNullCheck). `RedundantNullCheck` was from google/error-prone#5121. I had already taken some of its suggestions in 125fd02, but I'd been on the fence about these ones. What pushed me over the edge was that my 34f3253 causes failures in nullness checking. I'm sure I could find another way to resolve those, but this approach probably makes more sense, anyway: If we imagine that nullness is enforced as in Kotlin (or possibly someday Java), then the call to `checkEntryNotNull` would immediately throw a `NullPointerException`, possibly with no message, instead of allowing the method to execute far enough to produce our custom `NullPointerException`, which includes both the key and the value. (I think there were a handful of other parameters like this one on which I also had declined to add `@Nullable`. I'm not revisiting that right now, but we could someday.) RELNOTES=n/a PiperOrigin-RevId: 830586416
… with `skipPublishing`. ...by rolling back 119bd9b. The bug was fixed in [release 0.9.0](https://central.sonatype.org/publish/publish-portal-maven/#090), which we upgraded to in 453a788, and we've validated as much with AutoValue cl/831014897. PiperOrigin-RevId: 831051885
For some reason, cl/831919226 is failing presubmit: ``` Error fetching URL: https://errorprone.info/api/latest/ (java.io.FileNotFoundException: https://errorprone.info/api/latest/package-list) ``` The problem is unlikely to be related to that CL. It may have something to do with networking restrictions, which might be preventing GitHub Actions from accessing the Error Prone Javadoc? The problem reproduced when I reran the failing job. This CL adds `element-list`, not `package-list`, despite the path given in the error message: Error Prone's `package-list` seems to have been replaced by `element-list` [five years ago](google/error-prone@e0ac643). Also, I didn't try to include all of `element-list`, only the `annotations` packages, since that's all that is covered by `error_prone_annotations`. I haven't been able to reproduce the problem locally, even with the specific Temurin JDK that the failed build uses. RELNOTES=n/a PiperOrigin-RevId: 833473635
Fixes #8088 RELNOTES=n/a PiperOrigin-RevId: 833504486
…age. RELNOTES=n/a PiperOrigin-RevId: 834035085
PiperOrigin-RevId: 836830042
Bumps the github-actions group with 2 updates: [actions/checkout](https://github.com/actions/checkout) and [github/codeql-action](https://github.com/github/codeql-action). Updates `actions/checkout` from 5.0.0 to 6.0.0 - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@08c6903...1af3b93) Updates `github/codeql-action` from 4.31.2 to 4.31.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@0499de3...fe4161a) Fixes #8098 RELNOTES=n/a PiperOrigin-RevId: 838862593
Using XOR here meant that the `hashCode` of `A.converterTo(B)` was the same as the `hashCode` of `B.converterTo(A)`. (It also meant that the `hashCode` of `A.converterTo(A)` was 0, though that probably doesn't often matter). RELNOTES=n/a PiperOrigin-RevId: 839820133
RELNOTES=n/a PiperOrigin-RevId: 839979256
Uses ByteBuffers for much faster putInt, putChar, etc. This comes at some small cost to efficiency on bytes, but it's easily worth it overall. RELNOTES=Speed up AbstractNonStreamingHashFunction for non-bytes types PiperOrigin-RevId: 840238028
…lugin` for `guava-tests`. Compare 3c0e704, in which I was too lazy to search for remaining versions. I've now grepped for `'<version>'` and looked for remaining non-property versions. I'd been figuring that I should get around to this, but the impetus for doing it now is that I decided to ask Gemini an open-ended question about what could be improved in our `pom.xml` files, and this was its main recommendation. (It also suggested bumping the value in `requireMavenVersion` (but I might rather rip out that check entirely) and potentially removing the `plexus-io` workaround (but I'm not sure offhand if it's time yet).) RELNOTES=n/a PiperOrigin-RevId: 840494798
The reason for that method's existence, according to cl/10687480, was so that we wouldn't have to mix calls to instance methods on `stream` with calls to helper methods on `Serialization`: We could instead use _exclusively_ methods from `Serialization`. I'm not sure I would find that convincing on those merits, but I think we fall short even of that: We _still_ need to call an instance method on `stream`—namely, `defaultReadObject`. And at the time of cl/10687480, we were even mixing in a call to `stream.readInt()` in `ArrayListMultimap` (though we subsequently removed it). (I noticed `readCount` while looking at `Serialization` as part of #8099.) RELNOTES=n/a PiperOrigin-RevId: 840893040
Entertainingly, we've been getting three warnings in the same line:
```
com/google/common/collect/InternersTest.java:101: warning: [identity] use of a value-based class with an operation that expects reliable identity
WeakReference<Integer> signal = new WeakReference<>(canonical);
^
com/google/common/collect/InternersTest.java:101: warning: [identity] use of a value-based class with an operation that expects reliable identity
WeakReference<Integer> signal = new WeakReference<>(canonical);
^
com/google/common/collect/InternersTest.java:101: warning: [identity] use of a value-based class with an operation that expects reliable identity
WeakReference<Integer> signal = new WeakReference<>(canonical);
^
```
(I noticed these warnings while building for JDK 26 as part of #8099.)
RELNOTES=n/a
PiperOrigin-RevId: 841786271
…ion. This covers the first class from #8099. As part of doing that, I needed a way to create a new `ConcurrentHashMap` instances without failing the existing `countMap.isEmpty()` check in the constructor. To do that, I moved the check out of the constructor and into the `create(ConcurrentMap)` static factory method. Then I updated all existing users of the constructor to instead call `create(ConcurrentMap)`. Along the way, I noticed that we'd never removed a TODO about exposing `create(ConcurrentMap)` in the first place, so I removed that. Plus: - I updated the comment about why we override `toArray`. (Spoiler: We probably shouldn't override one of the two overloads anymore.) I also tweaked the name of a helper method. - I added `@Serial` annotations to our serialization-related methods, and I removed one such method's `@J2ktIncompatible` annotation, which was unnecessary because the entire class is `@J2ktIncompatible`. - other tiny tweaks, including in tests (Fun fact: Back when I was discussing with Gemini the alternative of switching to using default serialization, it noticed the existing incorrect type for `deserializedCountMap`. back then, the type was worth fixing just to be pedantic, but now it actually matters.) RELNOTES=`collect`: Changed `ConcurrentHashMultiset` deserialization to [avoid mutating `final` fields](https://openjdk.org/jeps/500). In extremely unlikely scenarios in which an instance of that type contains an object that refers back to that instance, this could lead to [a broken instance](https://docs.oracle.com/en/java/javase/25/docs/specs/serialization/input.html#the-readresolve-method:~:text=in%20cases%20where%20an%20object%20being%20serialized%20nominates%20a%20replacement%20object%20whose%20object%20graph%20has%20a%20reference%20to%20the%20original%20object) that throws `NullPointerException` when used. PiperOrigin-RevId: 841920488
…ullCheck`](https://errorprone.info/bugpattern/RedundantNullCheck) in the mainline. It was already present in the backport since a75d0f0. Also, resolve some other unnecessary differences between the mainline and backport (also from that CL). RELNOTES=n/a PiperOrigin-RevId: 842235059
…` deserialization. Compare to what we did for `ConcurrentHashMultiset` in 8240c7e. Fixes #8099 RELNOTES=`collect`: Changed `ImmutableMap` and `TreeMultiset` deserialization to [avoid mutating `final` fields](https://openjdk.org/jeps/500). In extremely unlikely scenarios in which an instance of that type contains an object that refers back to that instance, this could lead to [a broken instance](https://docs.oracle.com/en/java/javase/25/docs/specs/serialization/input.html#the-readresolve-method:~:text=in%20cases%20where%20an%20object%20being%20serialized%20nominates%20a%20replacement%20object%20whose%20object%20graph%20has%20a%20reference%20to%20the%20original%20object) that throws `NullPointerException` when used. PiperOrigin-RevId: 842237977
- Try to avoid suggesting that, if we leave a feature request unimplemented, that that implies that it is "without merit." - Tell contributors that they don't need to modify the `android` directory. (This question was [the motivation](#8112 (comment)) for my CL.) - Link to Google's practices for commit messages. - Update some links. RELNOTES=n/a PiperOrigin-RevId: 842265291
… which we can't use that comparator. This accommodates some apps that eagerly initialize internal Guava classes that they've seen used in previous runs. Currently, such apps crash when `UnsafeComparator` fails to initialize, either because of `--sun-misc-unsafe-memory-access=deny` or because of `-XX:+UseCompactObjectHeaders`. This CL makes the class initialization succeed, setting a flag to indicate whether we should actually use the resulting comparator. Really, failing class initialization has always been a gross way to operate. Concretely, we've seen similar tricks cause log spam on Android (fb109b0). (Granted, we'd expect `Unsafe` to remain available for a long time under Android, so we shouldn't see that kind of issue here—at least not unless optimizers like Proguard are removing `UnsafeComparator`, in which case we'd rather make them stop doing that, rather than silence the warning as we do here....) I also found it convenient to eliminate an `unchecked` warning as part of introducing `interface LexicographicalComparator`, and I suppressed some `deprecation` warnings for `Unsafe`. Finally, I belatedly updated some documentation that was still suggesting that `Unsafe` was our preferred implementation in all environments. RELNOTES=n/a PiperOrigin-RevId: 843239216
…` and `Enum`. Those types use identity equality. Also: - Fix parameter-order mixups in `EnumsTest` and `FuturesGetCheckedTest`. - Improve parameter names in `ObjectArraysTest`. RELNOTES=n/a PiperOrigin-RevId: 843321659
…ugpattern/FormatStringShouldUsePlaceholders) warnings. RELNOTES=n/a PiperOrigin-RevId: 843334741
…Class())`. A `Class`-equality assertion is better in some cases, but often it's not. And of course we like Truth. I've tried to migrate all the cases in which `isInstanceOf` makes sense. RELNOTES=n/a PiperOrigin-RevId: 843340055
…essWarnings warnings. ...again, having previously done so in 12bf71e. Some remaining warnings came up in 0f05bb4. RELNOTES=n/a PiperOrigin-RevId: 843385402
Along the way, simplify some tests in `util.concurrent` by using `FutureTask`. (I probably "should" use a single-threaded `Executor`, but then I have to deal with shutting it down....) RELNOTES=n/a PiperOrigin-RevId: 843417775
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
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]
Can you help keep this open source service alive? 💖 Please sponsor : )