| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
Like with providers, consumers get a merged view of all actions from the merged configured target (all other aspects + the base target).
I had to rejig the aspect value / configured aspect to be symmetric with rule configured targets.
I do not expect significant memory bloat from this. All lists / maps already existed, only extra fields have been added.
RELNOTES: Expose aspect actions provider to Skylark.
PiperOrigin-RevId: 201697923
|
|
|
|
|
|
|
| |
The memory savings from this flag are not worth the complexity, and it interferes with action restarting.
RELNOTES: Remove support for --discard_actions_after_execution.
PiperOrigin-RevId: 201077905
|
|
|
|
|
|
|
|
| |
invocation.
Also, makes it benign to registerInitialValue when memoization is disabled.
PiperOrigin-RevId: 191338253
|
|
|
|
| |
PiperOrigin-RevId: 190348986
|
|
|
|
| |
PiperOrigin-RevId: 190285465
|
|
|
|
|
|
|
|
|
| |
Given a target (for example from a skylark aspect), one will be able to access a list of actions that the target generated using "target.actions". This is without additional memory footprint.
Actions themselves are not fully exposed to skylark (and thus there isn't much meaning to gather from them in skylark yet). Access methods will follow soon.
RELNOTES: None.
PiperOrigin-RevId: 188098079
|
|
|
|
| |
PiperOrigin-RevId: 187397314
|
|
|
|
|
|
| |
come from Skylark, so we shouldn't crash. As a safety measure, subclasses of ActionLookupValue are now responsible for detecting action conflicts themselves.
PiperOrigin-RevId: 187095271
|
|
|
|
|
|
| |
Also make AspectKey#toString a little more informative.
PiperOrigin-RevId: 185600069
|
|
|
|
|
|
|
|
|
|
| |
Context implementations are currently empty, just doing the plumbing in this
change. Once this is in we can start passing along the ObjectCodecRegistry, which
will allow runtime codec resolution for classes not known at compile time.
We'll also inevitably add some memoization helpers, allowing us to optimize the
serialization process further.
PiperOrigin-RevId: 185305674
|
|
|
|
|
|
|
|
| |
to do.
Also change AspectDescriptor #isEmpty() semantics because they seemed like a bug to me.
PiperOrigin-RevId: 184319840
|
|
|
|
|
|
| |
SkyKey and perform the lookup in AspectFunction, in parallel with the lookup for the base configured target introduced in unknown commit.
PiperOrigin-RevId: 183399436
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/3863b536bcab8de2000f342c85c31c7ea91cccbe, we don't want to have to serialize/deserialize a BuildConfiguration in a SkyKey.
Cutting the edge to the aspect configuration will come in a follow-up.
PiperOrigin-RevId: 183117915
|
|
|
|
|
|
| |
removing the layer of indirection of getting SkyKey out of ActionLookupKey, which uses more memory for no reason.
PiperOrigin-RevId: 181658615
|
|
|
|
|
|
| |
If we are running with a single source root and not going to set up the execroot (since we know how to resolve all packages), we can avoid tracking loaded packages, since they're only used to set up the execroot.
PiperOrigin-RevId: 179234932
|
|
|
|
|
|
|
| |
This key context can be used by actions to share partial key computations, for instance when computing MD5s for nested sets.
RELNOTES: None
PiperOrigin-RevId: 177359607
|
|
|
|
|
|
| |
Part of the effort to simplify ConfiguredTargetFunction.
PiperOrigin-RevId: 169453435
|
|
|
|
| |
PiperOrigin-RevId: 168452997
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--noexperimental_enable_critical_path_profiling flags are all specified, then Bazel will delete Actions from ActionLookupValues as they are executed in order to save memory.
Because an already-run action may output an artifact that is only requested later in the build, we need to maintain a way for the artifact to look up the action. But in most cases we don't need to keep the action itself, just its output metadata.
Some actions unfortunately are needed post-execution, and so we special-case them.
Also includes dependency change with description:
Move action out of key. This keeps action references from polluting the graph -- actions are just stored in one SkyValue, instead of being present in SkyKeys.
This does mean additional memory used: we have a separate ActionLookupData object per Action executed. That may reach ~24M for million-action builds.
PiperOrigin-RevId: 151756383
|
|
|
|
|
|
|
|
| |
ConfiguredTargetValues. Also clear transitive packages for both, even for top-level targets.
This is not expected to save significant memory, but is expected to reduce the number of references to Packages, allowing them to be dropped more easily when discarding analysis cache and running in batch mode.
PiperOrigin-RevId: 151508877
|
|
|
|
|
|
|
|
| |
providers.
--
PiperOrigin-RevId: 147526961
MOS_MIGRATED_REVID=147526961
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an Aspect registered an action that an extra-action is
shadowing, its name is used when creating the extra-action's ID and
name.
Since recently, an aspect can see other aspects applied to the same
target. This CL record the names of other aspects applied to the target
as well, disambiguating the action owners.
--
PiperOrigin-RevId: 142264153
MOS_MIGRATED_REVID=142264153
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=139573590
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=139189444
|
|
|
|
|
|
|
|
|
| |
This involved refactoring BuildViewTestCase a bit so that its behavior is closer to that of Bazel with --experimental_interleave_loading_and_analysis.
RELNOTES:
--
MOS_MIGRATED_REVID=124816624
|
|
|
|
|
|
|
| |
Except in action execution logic (ActionExecutionFunction, SkyframeActionExecutor, etc.), switch Action interface references to either ActionAnalysisMetadata if possible or ActionExecutionMetadata.
--
MOS_MIGRATED_REVID=120723431
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=119141878
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously AspectFunction was using an Aspect from the SkyKey, which
might have been stale.
This CL fixes the bug as uncovered in the test (see SkylarkAspectsTest),
but further refactoring is needed since SkylarkAspectClass equals() is
incorrect, and in fact obtaining the Skylark aspect definition should
always introduce Skyframe dependency.
--
MOS_MIGRATED_REVID=119137636
|
|
|
|
|
|
|
| |
are created, as opposed to when they are requested from the ParallelEvaluator. That delay can lead to large memory spikes and churn.
--
MOS_MIGRATED_REVID=116224565
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order for Aspects to support dynamic configuration, they need to have two
configurations: one to instantiate the Aspect with, containing all the fragment
dependencies of the Aspect itself, and one to create the ConfiguredTargetValue.key
with, containing only the dependencies of the Rule. This expands AspectKey to
have a second configuration, although it currently does not populate that key with
anything different.
--
MOS_MIGRATED_REVID=115997454
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
internally. The load location for a Skylark Aspect is specified via a PathFragment, for consistency with current non-Aspect Skylark loads.
This should be a semantics-preserving change for users. In a subsequent CL, I'll change the Skylark syntax to allow load statements to use labels as well as paths, with the goal of eventually deprecating the latter.
Also:
- Removed the hack for handling relative loads in the prelude file.
- Refactored some redundant functionality in PackageFunction and SkylarkImportLookupFunction for handling loads.
- Removed the ability to put the BUILD file for the package containing a Skylark file under a different package root than the Skylark file itself. This functionality isn't currently used and is inconsistent with Blaze's handling of the package path elsewhere.
- Added BUILD files to a number of tests that load Skylark files; this is consistent with the requirement that all Skylark files need to be part of some package.
- Changed the constants used to set the location of the prelude file from paths to labels.
--
MOS_MIGRATED_REVID=107741568
|
|
|
|
|
|
|
|
| |
Aspect => ConfiguredAspect
AspectWithParameters => Aspect
--
MOS_MIGRATED_REVID=107375211
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=106848269
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=106694515
|
|
|
|
|
|
|
| |
For native aspects, AspectClass is a facade for Class<AspectFactory<...>>.
--
MOS_MIGRATED_REVID=105986390
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=105851371
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=105844221
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Uses tests that don't run on Bazel
*** Original change description ***
Implement aspect(...) Skylark function.
--
MOS_MIGRATED_REVID=105808850
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=105596479
|
|
|
|
|
|
|
|
|
|
|
| |
The headers were modified with
`find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'`
And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan.
The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand.
--
MOS_MIGRATED_REVID=103938715
|
|
|
|
|
|
|
|
|
|
| |
- Label parsing can be simplified
- lib.syntax is only contains the code for Skylark and is reasonably independent from the problem domain of building things
This change is mostly only changes to imports declarations. The rest is reversing the dependency between :cmdline and :syntax and moving a tiny amount of code between Printer and FilesetEntry and the addition of SkylarkPrintableValue that I couldn't be bothered to separate out into its own change.
--
MOS_MIGRATED_REVID=103527877
|
|
|
|
|
|
|
| |
AspectValue.
--
MOS_MIGRATED_REVID=102643564
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=102126786
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=101033236
|
|
|
|
|
|
|
|
|
|
|
| |
.checksum() method that is computed from the checksum of the build options. Also remove Fragment.cacheKey() and Fragment.getName().
The reasoning is that within a single build, if two BuildConfigurations share the same BuildOptions, they must be the same because BuildConfiguration can only be a function of BuildOptions, specific targets (which stay the same during a build) and BlazeDirectories (which stay the same during the lifetime of a server). Between different builds if the configurations are recreated, they will always be considered different because Java reference equality (==) is used for comparing BuildConfigurations.
Also remove "Serializable" tags from configuration-related things.
--
MOS_MIGRATED_REVID=97107881
|
|
--
MOE_MIGRATED_REVID=85702957
|