| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
one_version_whitelist attribution on the java_toolchain.
Fixes bazelbuild/bazel#4682
RELNOTES: n/a
PiperOrigin-RevId: 192181587
|
|
|
|
| |
PiperOrigin-RevId: 190392567
|
|
|
|
|
|
|
|
|
| |
lib.analysis.actions -> lib.actions.
These are fundamental types that want to sit alongside types like Spawn.
RELNOTES: None
PiperOrigin-RevId: 185887971
|
|
|
|
|
|
| |
This is needed to migrate JavaCompileAction away from CustomMultiArgv.
PiperOrigin-RevId: 184136486
|
|
|
|
|
|
|
| |
This feature is not yet available for Bazel users.
RELNOTES: n/a
PiperOrigin-RevId: 175226288
|
|
|
|
|
|
|
|
| |
Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own.
This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually.
PiperOrigin-RevId: 175033526
|
|
|
|
|
|
| |
This is necessary for the upcoming Skylark implementation of param files.
PiperOrigin-RevId: 168744486
|
|
|
|
|
|
| |
This whole CL was done using IDE refactoring tools and should be safe.
PiperOrigin-RevId: 168275575
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In converting SpawnAction.Builder (multi-thousand line CL) users directly to CustomCommandLine I didn't like the resulting loss of readability, and the methods didn't feel very discoverable. Unless it's very convenient and readable to use CustomCommandLine, people will resort to non-memory efficient patterns by default. I'm holding that CL for this, which should offer a nicer interface.
This CL removes VectorArg from the API contact surface area, instead creating 64 overloads for every valid combination of parameters. Pretty sad, but the methods dispatch straight to internal helper methods so it's mostly boilerplate to the tune of +400 LOC.
Other changes:
* Change ImmutableCollection -> Collection and copy the args directly into the internal args vector. Saves on collection object overhead and saves users from having to create immutable copies.
* Change some names, notably add -> addAll for collection methods
* Create additional missing overloads
* Fix JavaDoc
RELNOTES: None
PiperOrigin-RevId: 165943879
|
|
|
|
| |
PiperOrigin-RevId: 165925128
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allowing add(Object) is too loose and can easily lead to programmer mistakes.
Because of type erasure, we can't use the same overload name for (eg.) add(NestedSet<String>) and add(NestedSet<Artifact>). The API is overhauled to use the same terms everywhere, eg. "add", "addPaths", "addExecPaths". This is similar to how it used to be a few CLs ago.
The API is overhauled to make sure it's consistent for all types. While tedious, the facade methods immediately dispatch to internal helpers, so implementation wise it's not too heavy.
While large, this CL is almost entirely an automated refactor.
PiperOrigin-RevId: 165358287
|
|
|
|
|
|
|
|
|
| |
Apart from updating CustomCommandLineTest this CL is entirely automated.
We also sneak in a rename of addFormat -> addFormatted.
RELNOTES: None
PiperOrigin-RevId: 164870140
|
|
|
|
|
|
|
|
|
|
| |
Consumers using spawn action builder now have access to handy overloads that behind the scene do a lazy String.format. In 95% of cases progress messages are expressible as 0, 1, or 2 argument String.formats.
This saves memory because the format string is constant and shared between all actions, and the captured subjects are usually live on the heap anyway (eg. labels).
Skylark still computes its progress messages eagerly. If we want similar savings there I'd have to follow up with a Skylark proposal.
PiperOrigin-RevId: 164068816
|
|
|
|
| |
PiperOrigin-RevId: 161910195
|
|
|
|
|
|
| |
updates --experimental_one_version_enforcement from a boolean flag to a 3-state enum (OFF, WARNING, ERROR).
PiperOrigin-RevId: 154978203
|
|
rules: If the collection of jars for a java_binary contain more than one
instance of the same class, one of them will be arbitrarily loaded at runtime.
This is problematic if the instances of the class are not identical, as methods
or fields from one class version might be missing in the other, leading to
runtime failures when methods are missing.
This change adds an experimental flag to enable one version enforcement. The
actual enforcement tool will come later.
--
PiperOrigin-RevId: 147166361
MOS_MIGRATED_REVID=147166361
|