Update repo to current version #1
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
PiperOrigin-RevId: 503916049
PiperOrigin-RevId: 505840946
PiperOrigin-RevId: 516590803
…cates() is specified. PiperOrigin-RevId: 517978849
…sses with ASM, so Guice is less finicky about the precise .class version & ASM version. A while ago I had tried to do this by ignoring UnsupportedOperationException, but per #1654, ASM doesn't always throw UOE. This change will log a single failure when Guice encounters an exception while reading classfiles and warn that ASM may be out of date. The consequences of this failing _all_ line number reading (due to, say, an accidental bug introduced while parsing classfiles) is that Guice won't emit line numbers for bind statements in modules (as binding source locations). A number of other tests would fail in that scenario, warning us that something is off. PiperOrigin-RevId: 524387180
…would previously fail:
* T1: Enter `lockOrDetectPotentialLocksCycle`:
- Lock CAF.class, add itself to `lockThreadIsWaitingOn`, unlock CAF.class
- Lock the cycle detecting lock (CDL)
- Lock CAF.class, mark itself as `lockOwnerThread`, remove itself from `lockThreadIsWaitingOn`
- Exit `lockOrDetectPotentialLocksCycle`
* T1: Re-enter `lockOrDetectPotentialLocksCycle`:
- Lock CAF.class, add itself to `lockThreadIsWaitingOn`, unlock CAF.class
T2: Enter `lockOrDetectPotentialLocksCycle`
- Lock CAF.class, invoke `detectPotentialLocksCycle`.
At this point, `detectPotentialLocksCycle` will now loop forever, because the `lockOwnerThread` is also in `lockThreadIsWaitingOn`. During the course of looping forever, it will OOM, because it's building up an in-memory structure of what it thinks are cycles.
The solution is to avoid the re-entrant T1 from adding itself to `lockThreadIsWaitingOn` if it's already the `lockOwnerThread`. It's guaranteed that it won't relinquish the lock concurrently, because it's the exact same thread that owns it.
Fixes #1635 and Fixes #1510
PiperOrigin-RevId: 525182219
PiperOrigin-RevId: 525219514
… with the new version. Fixes #1624. PiperOrigin-RevId: 525219685
…nd/or crash inside Guava's LoadingCache. The problem had to do with the fact that Guice eagerly stores uninitialized JIT bindings in an attempt to allow circular dependencies, and Guice also attempts to cleanup failed JIT bindings (to remove these uninitialized JIT bindings). The JIT binding cache was a guard against a recursive call back into the constructor's cache, but we were removing that guard. We now only remove the guard if we aren't in the process of loading that JIT binding. The failed JIT binding is naturally cleaned up later on, as the existing & new tests attest to. Fixes many issues: - Fixes #1633 - Fixes #785 - Fixes #1389 - Fixes #1394 Many thanks to @swankjesse for the test-case added in #1389 that was helpful in diagnosing the problem, and to @PaulFridrick for the diagnoses in #1633. PiperOrigin-RevId: 525219839
… returned in any order from Method.getGenericExceptionTypes. Fixes #1603. (This does not use the suggested code from the original PR, and does not attempt to change the `testManyMethods` method because we assume that repeated calls to `getDeclaredMethods` will always return the same order of methods. If that ever changes, we can deal with it then.) PiperOrigin-RevId: 525220025
…ossible. Fixes #1556 PiperOrigin-RevId: 525231598
…date the version we use. PiperOrigin-RevId: 525459640
…e system line separator and always using \n explicitly. (We were previously inconsistent: many places used \n, and many other places used %n with a formatter, which would end up being the system line separator.) This allows tests to pass on Windows, where the line separator is different. Also update tests to do a run with the windows line separator, to catch regressions. Fixes #1213. PiperOrigin-RevId: 525558598
PiperOrigin-RevId: 525564484
…Fixes #1171. PiperOrigin-RevId: 525564737
…ou only need it if you want to perform null analysis on the code). Fixes #1172 PiperOrigin-RevId: 525741584
PiperOrigin-RevId: 525805514
PiperOrigin-RevId: 525828170
#1071. PiperOrigin-RevId: 525898592
…ProvidedBy when using the @ProvidedBy as the provider. Notably, this does *not* change things to allow scoping annotations on interfaces or abstract classes (even though theoretically we could, because the @ProvidedBy will be instantiating it). Scopes on abstract classes|interfaces will still throw an exception about the scope being misplaced. Fixes #251 and fixes #1319. PiperOrigin-RevId: 526009187
…because it leads to leaks. Fixes #739, fixes #997, fixes #730, fixes #985, fixes #959, fixes #731. This also adds an optional Options to the JpaPersistModule constructor, if users wish to use the legacy behavior. This is a breaking change, but to a better default value. Users who want to keep the dangerous form can opt back in with the options. PiperOrigin-RevId: 526106112
PiperOrigin-RevId: 576885259
PiperOrigin-RevId: 577308018
PiperOrigin-RevId: 578306054
PiperOrigin-RevId: 578574921
PiperOrigin-RevId: 581989087
…referenced libs that aren't published anymore. PiperOrigin-RevId: 597242944
…tedSize, and avoid an extra T[] array allocation when permitDuplicates==true. Since the normal usage should be that the items in the values array are all unique, and ImmutableSet#copyOf will create an initial list of max(4, sqrt(length)) if length>4, but then grows that list to length (or larger) if the array was all unique (and then resize is back down during build()). While here, the T[] values array is also only needed to be filled in when permitDuplicates==false (for the error message if duplicates were detected). PiperOrigin-RevId: 597244931
New commit: google/bazel-common@2a6b640 This helps with google/truth#746. PiperOrigin-RevId: 602832261
…ruth.assertThat`, and qualify others. By "qualify," I mean that, instead of static importing `Truth8.assertThat`, we write "`Truth8.assertThat(...)`" at the call site. This is normally the opposite of what we recommend. However, it's a necessary step in our migration: We are copying all the `Truth8` methods to `Truth`, and we can't do that if any files static import both `Truth.assertThat` and `Truth8.assertThat` (because it produces a compile error about ambiguous overloads). To unblock that, we're moving callers away from the static import. We will update static analysis to stop suggesting the import. A later step will migrate these callers to the new `Truth.assertThat` methods, which we will static import. The `Truth8` methods will be hidden in the future. All callers will use `Truth`. PiperOrigin-RevId: 603073706
…v1.4.0). This makes available the rest of the Truth APIs that were recently added in Google's monorepo. It may be worth also updating to the _following_ version of Truth after it's released, but the purpose of that release will mostly be to deprecate `Truth8`. So, if you just avoid using `Truth8` now (starting by approving any migration CLs that I send your way), then there will be little need for that upgrade. Or, more to the point: I don't expect to keep sending you weekly upgrade CLs after this one :) PiperOrigin-RevId: 604719853
…assertThat`. The `Truth8` methods will be deprecated (or hidden) in the future. Callers should move to `Truth`. Some (but not all) of the CLs in this batch require Truth [1.4.0](https://github.com/google/truth/releases/tag/v1.4.0). I submitted a CL earlier today to (I hope) perform that upgrade for your project. PiperOrigin-RevId: 604731456
PiperOrigin-RevId: 609175545
PiperOrigin-RevId: 609419903
…his is useful in some cases where the scanner bindings need more information from the module currently being scanned. PiperOrigin-RevId: 615788414
RELNOTES=n/a PiperOrigin-RevId: 617628676
PiperOrigin-RevId: 619545649
… base level is JDK11. PiperOrigin-RevId: 620889085
Loads are being added in preparation for moving the rules out of Bazel and into `rules_java`. PiperOrigin-RevId: 621873514
Loads are being added in preparation for moving the symbols out of Bazel and into `rules_java`. PiperOrigin-RevId: 624858712
…it works on the latest macos on github. Also update to the latest Bazel version that supports JavaInfo rule imports, and fix things that break w/ the latest bazel version (requiring imports for defining package statements if a package_info.java exists, and not using `@local_jdk//:jar`). PiperOrigin-RevId: 631081930
…d can be simplified to just the input parameter. PiperOrigin-RevId: 631556426
…record the state in a public boolean field. Change UnsafeClassDefiner to check HiddenClassDefiner state and set UNSAFE_DEFINER as null if there's an error. An IllegalStateException is thrown if HiddenClassDefiner.define() is called in that case. PiperOrigin-RevId: 631862800
…nning on JDK >=17 with Unsafe.defineAnonymousClass removed. PiperOrigin-RevId: 632544907
PiperOrigin-RevId: 635570248
PiperOrigin-RevId: 635857202
PiperOrigin-RevId: 659586774
PiperOrigin-RevId: 659586785
PiperOrigin-RevId: 689368258
…rent packages. PiperOrigin-RevId: 696172862
…e is a wildcard type and the other is a non-wildcard type that is mentioned in the extends/super clause of the wildcard type (e.g. Optional<Foo> vs. Optional<? extends Foo>). PiperOrigin-RevId: 696949702
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.
No description provided.