| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 167608048
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel now creates all SpawnActions in
AndroidBinary, AndroidCommon, and DexArchiveAspect
such that they use the default shell environment.
The benefit of this is that these actions will
have a well-controlled, minimal environment, and
most importantly they'll have valid TMP and TEMP
environment variables, which is necessary for temp
file creaion on Windows.
I created this commit for the same reason as
https://github.com/bazelbuild/bazel/commit/0abf5fa2d64c76def5a8fa0f960b73ce0566af4d
See https://github.com/bazelbuild/bazel/issues/3659
Change-Id: Ice42ea6424af8984d3c382ab01727e04cbd0c1b4
PiperOrigin-RevId: 167285724
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change forces use of CustomCommandLine.Builder, which has a richer interface for constructing memory-efficient command lines. It will also permit surveying the code base for inefficient patterns using an IDE.
This change was done by hand and split using Rosie to assist with rollbacks in case of bugs. Reviewers, please pay particular attention to:
* Each all to addInputArgument/addOutputArgument should come with a corresponding matching pair to SpawnAction.Builder#addInput and CustomCommandLine.Builder#addExecPath (eg.).
* The commandLine must be set on the SpawnAction using SpawnAction.Builder#setCommandLine.
Note that most calls to addPrefixed("arg=", val) should be more idiomatically expressed as add("arg", val), but this involves changing tests and making sure that the command line tools can accept the format.
PiperOrigin-RevId: 166104375
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of having custom ArgvFragments for every combination of desired things, we make a combined "interpreter" of argvs. This saves memory and simplifies things as we do not have to allocate a strategy instance per call to args (instead pushing a single shared instance, followed by the args).
The generic interpreter does have a lot of branching compared to the bespoke implementations, but because the branch is always the same for long stretches the branch predictor should easily be able to handle it with minimal overhead (~1 cycle per branch IIRC).
This CL also elevates that we either want a NestedSet or an ImmutableCollection to the surface of the API, so consumers understand the cost when they call it with a non-immutable collection. Most of the changes in clients is due to this.
To cut down on CL churn, @Deprecated forwarding methods are added to CustomCommandLine. These will be removed in a separate CL using IDE inlining.
RELNOTES: None
PiperOrigin-RevId: 164725370
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
With a few manual fixes for readability.
RELNOTES: None.
PiperOrigin-RevId: 160582556
|
|
|
|
|
|
| |
Cuts down on file count and makes it easier to find these methods.
PiperOrigin-RevId: 159560422
|
|
|
|
|
|
|
|
|
|
|
|
| |
friends.
The wrapping provider contains its own provider map containing any providers that may conflict. This can be used generally for any aspect that wants to override its base providers (during migration), and due to the generality we should be able to cut down on code size and complexity.
Once we have this, we can more easily and uniformly bind aspects to Skylark for aspect-on-aspect functionality. The Skylark providers can be instantiated with a wrapping provider if one is present, or fall through to the base target if they aren't.
We will also likely save a bit of memory from cutting down on wrapping classes.
PiperOrigin-RevId: 159461325
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 158498863
|
|
|
|
|
|
|
|
| |
tool during incremental dexing
RELNOTES: none
PiperOrigin-RevId: 152838197
|
|
|
|
|
|
|
|
|
|
|
| |
provide a provider.
Previously we always executed the function, but didn't add the aspect to
the deps.
--
PiperOrigin-RevId: 148887089
MOS_MIGRATED_REVID=148887089
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 148275963
MOS_MIGRATED_REVID=148275963
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 147876411
MOS_MIGRATED_REVID=147876411
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 147793223
MOS_MIGRATED_REVID=147793223
|
|
|
|
|
|
|
|
| |
providers.
--
PiperOrigin-RevId: 147526961
MOS_MIGRATED_REVID=147526961
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Vanilla roll forward
--
PiperOrigin-RevId: 147512649
MOS_MIGRATED_REVID=147512649
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 147416635
MOS_MIGRATED_REVID=147416635
|
|
|
|
|
|
|
|
| |
[] can be fixed.
--
PiperOrigin-RevId: 147094979
MOS_MIGRATED_REVID=147094979
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145744124
MOS_MIGRATED_REVID=145744124
|
|
|
|
|
|
|
|
|
| |
This functionality is never used, have never been exposed to Skylark
and is a continuous pain to maintain and test.
--
PiperOrigin-RevId: 145079832
MOS_MIGRATED_REVID=145079832
|
|
|
|
|
|
|
|
| |
multiple jars have the same simple filename (e.g., l.jar)
--
PiperOrigin-RevId: 140880491
MOS_MIGRATED_REVID=140880491
|
|
|
|
|
|
|
| |
against rules. Aspects can attach to a rule if at least one set of required providers are present on the rule.
--
MOS_MIGRATED_REVID=140605023
|
|
|
|
|
|
|
|
| |
Also clean up the setting of aspect name in ConfiguredAspect and
AspectDefintion - it is now obtained from the AspectClass.
--
MOS_MIGRATED_REVID=140357052
|
|
|
|
|
|
|
| |
JavaCompilationInfoProvider is missing
--
MOS_MIGRATED_REVID=139842250
|
|
|
|
|
|
|
| |
This includes applying desugaring for mobile-install's stub apk.
--
MOS_MIGRATED_REVID=136111631
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=133436157
|
|
|
|
|
|
|
|
|
|
|
|
| |
by class.
TransitiveInfoProviderMap enforces that the provider implements the interface it's keyed by
and provides accessors the reduce the amount of casting. This in general reduces boilerplate throughout wherever TransitiveInfoProviders are mapped by their class.
Also add shorthand for adding a provider where it only implements TransitiveInfoProvider once, reducing the redundant specification of the TransitiveInfoProvider class. Infer the class as the exclusive direct implementor of TransitiveInfoProvider to account for special cases like AutoValue and LicenseProvider.
--
MOS_MIGRATED_REVID=133386336
|
|
|
|
|
|
|
|
|
| |
"supports-workers" execution info tag.
This is a new requirement which helps Blaze decide whether an action can be executed via workers or not.
--
MOS_MIGRATED_REVID=126279864
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=123149803
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rollback of commit e37c55eccbd4516b2db7aaf58ef95209dfad3ed4 is complete so rolling this semantically unrelated change forward again
*** Original change description ***
Automated [] rollback of commit b8946eabd60a199a66a1892701d52d9801c7fb1a.
--
MOS_MIGRATED_REVID=122736257
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=122626656
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=122620007
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=122473346
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=122342484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NativeAspectClass.
This a large refactoring of the aspects, currently we have the following:
- AspectClasses: The interface AspectClass is a implemented by either
SkylarkAspectClass or NativeAspectClass<NativeAspectFactory>.
They are wrappers for the AspectFactories and they hold the information about
the Class<> of the factory.
- AspectFactories (FooAspect.java): Represented by the interfaces
ConfiguredAspectFactory and NativeAspectFactory, also by
the interface ConfiguredNativeAspectFactory which is the union of the two
aforementioned interfaces.
All aspects implement ConfiguredNativeAspectFactory except Skylark aspects
which implement only ConfiguredAspectFactory.
After this CL the distinction between NativeAspectFactories and NativeAspectClasses
dissappear, namely aspect that extends NativeAspectClass is considered native
and if it implements ConfiguredAspectFactory it is configured.
Therefore the interfaces NativeAspectFactory and ConfiguredNativeAspectFactory
both disappear.
With this refactoring the aspectFactoryMap in the ConfiguredRuleClassProvider
changes its type from (String -> Class<? extends NativeAspectClass>)
to (String -> NativeAspectClass) which means it is now able to have an instance
of the aspect instead of its Class only.
By doing this, it is now possible to pass parameters when creating an
aspect in the ConfiguredRuleClassProvider.
--
MOS_MIGRATED_REVID=120819647
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119999213
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119104560
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=118969066
|
|
--
MOS_MIGRATED_REVID=117186609
|