| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
user_compile_flags
Also add magic to a feature named 'unfiltered_compile_flags' so the flags
expanded from it are not subject to nocopt filtering.
This is encore of https://github.com/bazelbuild/bazel/commit/268c0bcbf79f9f3f72d95fa51af0f1b18c5ce29e that was rolled back because it regressed
memory.
RELNOTES: None.
PiperOrigin-RevId: 167989075
|
|
|
|
| |
PiperOrigin-RevId: 167751263
|
|
|
|
|
|
|
|
|
| |
Split collect, concurrent, vfs, windows into package-level BUILD files.
Move clock classes out of "util", into their own Java package.
Move CompactHashSet into its own Java package to break a dependency cycle.
Give nestedset and inmemoryfs their own package-level BUILD files.
PiperOrigin-RevId: 167702127
|
|
|
|
|
|
|
|
|
|
| |
user_compile_flags
Also add magic to a feature named 'unfiltered_compile_flags' so the flags
expanded from it are not subject to nocopt filtering.
RELNOTES: None.
PiperOrigin-RevId: 167587189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke several tests in nightly.
[]
*** Original change description ***
Rollforward #2 of "AppleBinary and AppleStaticLibrary no longer propagate unwrapped ObjcProvider", after changes made to apple bazel rules to be compatible.
RELNOTES: None.
PiperOrigin-RevId: 167312716
|
|
|
|
| |
PiperOrigin-RevId: 167154793
|
|
|
|
|
|
|
|
|
|
| |
- Move ProfilerInfo into a subpackage (it's not necessary for profiling, just for analyzing a profile).
- Make some fields in Profiler public for ProfileInfo.
- Mark Profiler as ThreadSafe; there's no cyclic dependency here.
This is based on ulfjack's microbazel patch series: https://github.com/ulfjack/bazel/commit/44553fcac0fc876784d8f48c2e577d8c999712de
PiperOrigin-RevId: 167121952
|
|
|
|
|
|
|
| |
unwrapped ObjcProvider", after changes made to apple bazel rules to be compatible.
RELNOTES: None.
PiperOrigin-RevId: 167061765
|
|
|
|
|
|
| |
that is accessible to the c++ rules.
PiperOrigin-RevId: 166934390
|
|
|
|
|
|
|
| |
it turns out these keys are still used by objc_framework, so cannot be removed.
RELNOTES: None.
PiperOrigin-RevId: 166895085
|
|
|
|
| |
PiperOrigin-RevId: 166889783
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 166889164
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 166874734
|
|
|
|
| |
PiperOrigin-RevId: 166849610
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 166756809
|
|
|
|
| |
PiperOrigin-RevId: 166722992
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Reason for previous rollback was identified as being a memory regression causing some cases to hit java heap limit. Proposal is to increase java heap limit to compensate and just go with the original change.
*** Original change description ***
Automated rollback of commit 6cfffdf37e11018c7e6e2cabc90440d6d29c819b.
PiperOrigin-RevId: 166426608
|
|
|
|
|
|
|
|
|
|
|
| |
rule in use and expose data in XcodeConfigProvider to Skylark.
This gives us a way to discover Xcode version information from Skylark in a way other than by AppleConfiguration, which in turn makes it possible to remove said data (and thus dependencies on BUILD files) from AppleConfiguration.
Work towards https://github.com/bazelbuild/bazel/issues/3424 .
RELNOTES: None.
PiperOrigin-RevId: 166311454
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This paves the way for Skylark-side compact command lines that can fail during expansion.
In general, expansion happens in these scenarios:
* Action execution expands the command line to execute it. This is fine since we are well equipped already to handle failing actions.
* In the analysis phase we expand command lines to investigate whether we need a params file. This could be moved to the execution phase, which would have the benefit of getting params files out of the action graph and saving memory.
* Key computation expands the command line. This could be fixed by allowing command lines to compute their own keys (which wouldn't try to expand the command line). This could have the benefit of being more efficient.
* Extra actions expand the command line to construct the extra action proto. This could maybe be deferred to the execution phase (writing the extra action), which would also be more memory efficient.
For failed key computations, we return a singleton "error" key. This means multiple actions that will fail will map to the same key. These actions will necessarily fail if executed, so we should not need to worry about these ending up in the action cache. If we do manage to make the command line compute its own keys then this will become moot in the future.
RELNOTES: None
PiperOrigin-RevId: 166266385
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 166106115
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 166097992
|
|
|
|
|
|
|
|
| |
Prerequisite to implementing shape-declaration and shape-sharing
for declared providers, and cleaning up NativeInfo interface.
RELNOTES: None.
PiperOrigin-RevId: 166057070
|
|
|
|
|
|
| |
These files are supplemental inputs that should always be passed to the linker regardless of relationships between dependent binaries.
PiperOrigin-RevId: 165982025
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
closure.
PiperOrigin-RevId: 165934905
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 165910455
|
|
|
|
| |
PiperOrigin-RevId: 165730337
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: Removing a few unused objc_provider keys.
PiperOrigin-RevId: 165230824
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 165215334
|
|
|
|
|
|
|
|
| |
This flag has been a noop for a while.
RELNOTES[INC]: Noop flag --deprecated_generate_xcode_project deleted.
PiperOrigin-RevId: 165199302
|
|
|
|
|
|
|
|
|
| |
This enforces certain memory-efficient patterns. For deliberate use of dynamic strings, explicitly named overloads are introduced, with javadoc that guides the programmer into making the right choice.
This CL is a memory no-op on benchmarks, but it tries to prevent backslide by making sure programmers make conscious choices when they construct their command lines.
RELNOTES: None
PiperOrigin-RevId: 165185997
|
|
|
|
|
|
| |
of CcToolchainProvider as a "toolchain" in platform-based toolchain resolution.
PiperOrigin-RevId: 165185303
|
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/21436e062a12b64c8bee665b0cf79dfe48cff114.
That change broke module maps that depended on the transitive headers from ObjC protos.
RELNOTES: None
PiperOrigin-RevId: 165010275
|
|
|
|
|
|
| |
thinning is enabled.
PiperOrigin-RevId: 164884344
|
|
|
|
|
|
|
|
|
| |
Apart from updating CustomCommandLineTest this CL is entirely automated.
We also sneak in a rename of addFormat -> addFormatted.
RELNOTES: None
PiperOrigin-RevId: 164870140
|
|
|
|
|
|
|
|
| |
These are depended upon by analysis code, so need to live in the same library
as lib.analysis. Moving them here makes it possible to split the build-base
library into separate libraries for analysis, execution, and rules.
PiperOrigin-RevId: 164847161
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 164590595
|
|
|
|
|
|
|
| |
of full artifact path"
RELNOTES: None.
PiperOrigin-RevId: 164496520
|
|
|
|
|
|
|
| |
This is part of splitting up the build-base library into separate libraries for
analysis, exec, and rules.
PiperOrigin-RevId: 164446955
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 164031163
|
|
|
|
| |
PiperOrigin-RevId: 163889699
|
|
|
|
|
|
|
|
|
|
|
| |
This cl changes copts to be immutable (and changes addCopts methods into
setCopts, so it's simpler to reason about copts) and exposes copts as a build
variable. It also introduces CompileBuildVariablesTest, similar to
LinkBuildVariablesTest, to test that right build variables are exposed for right
actions.
RELNOTES: None.
PiperOrigin-RevId: 163876774
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks some iOS Photos targets: []
*** Original change description ***
Framework dependency subtraction uses runfiles path instead of full artifact path
RELNOTES: None.
PiperOrigin-RevId: 163732608
|
|
|
|
|
|
|
|
| |
Follows
https://docs.google.com/document/d/1aAIVWvHPERDz2cv_PCFGwr8dvh5FcAkENFoRsNS4clk/.
RELNOTES: None.
PiperOrigin-RevId: 163728291
|
|
|
|
|
|
|
| |
path
RELNOTES: None.
PiperOrigin-RevId: 163484010
|
|
|
|
|
|
|
| |
Also fix the remaining violations.
RELNOTES: None.
PiperOrigin-RevId: 163391215
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 163343931
|