aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/skyframe/AspectValue.java
Commit message (Collapse)AuthorAge
* Expose aspect actions from Skylark.Gravatar tomlu2018-06-22
| | | | | | | | | | | 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
* Remove support for --discard_actions_after_execution.Gravatar tomlu2018-06-18
| | | | | | | 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
* Moves the decision to enable memoization from codecs to the top-level ↵Gravatar shahan2018-04-02
| | | | | | | | invocation. Also, makes it benign to registerInitialValue when memoization is disabled. PiperOrigin-RevId: 191338253
* Memoize AspectValue serialization (oops).Gravatar janakr2018-03-24
| | | | PiperOrigin-RevId: 190348986
* @AutoCodec AspectValue.Gravatar janakr2018-03-23
| | | | PiperOrigin-RevId: 190285465
* Expose an actions provider on RuleConfiguredTarget instances.Gravatar cparsons2018-03-06
| | | | | | | | | 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
* Deletes CODEC fields now that they are no longer needed.Gravatar shahan2018-02-28
| | | | PiperOrigin-RevId: 187397314
* Fail gracefully on conflicting actions generated by an aspect. These can ↵Gravatar janakr2018-02-26
| | | | | | 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
* @AutoCodec AspectValue$AspectKey.Gravatar janakr2018-02-13
| | | | | | Also make AspectKey#toString a little more informative. PiperOrigin-RevId: 185600069
* Add context argument to ObjectCodec.{serialize,deserialize}Gravatar michajlo2018-02-11
| | | | | | | | | | 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
* Start process of tagging AspectKey. Still a lot of subclasses of AspectClass ↵Gravatar janakr2018-02-02
| | | | | | | | to do. Also change AspectDescriptor #isEmpty() semantics because they seemed like a bug to me. PiperOrigin-RevId: 184319840
* Remove aspect configuration from AspectKey. Instead, store an appropriate ↵Gravatar cpeyser2018-01-26
| | | | | | SkyKey and perform the lookup in AspectFunction, in parallel with the lookup for the base configured target introduced in unknown commit. PiperOrigin-RevId: 183399436
* Stop storing the base configuration in AspectKey. As with ↵Gravatar janakr2018-01-24
| | | | | | | | 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
* Convert ActionLookupKey implementations to directly implement SkyKey, ↵Gravatar janakr2018-01-11
| | | | | | removing the layer of indirection of getting SkyKey out of ActionLookupKey, which uses more memory for no reason. PiperOrigin-RevId: 181658615
* Optionally allow loaded packages to not be tracked.Gravatar janakr2017-12-15
| | | | | | 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
* Add ActionKeyContext to Action#getKey.Gravatar tomlu2017-11-29
| | | | | | | 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
* Move aspect resolution out of ConfiguredTargetFunction.Gravatar gregce2017-09-21
| | | | | | Part of the effort to simplify ConfiguredTargetFunction. PiperOrigin-RevId: 169453435
* Remove outdated references to static vs. dynamic configurations.Gravatar gregce2017-09-13
| | | | PiperOrigin-RevId: 168452997
* If --batch, --keep_going, --discard_analysis_cache, and the new ↵Gravatar janakr2017-03-31
| | | | | | | | | | | | | | | --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
* Clear AspectValues when discarding analysis cache, along with ↵Gravatar janakr2017-03-29
| | | | | | | | 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
* Restrict aspects visible to other aspects according to their advertised ↵Gravatar Dmitry Lomov2017-02-15
| | | | | | | | providers. -- PiperOrigin-RevId: 147526961 MOS_MIGRATED_REVID=147526961
* Names of extra-action protos now take into account all aspect names.Gravatar Dmitry Lomov2016-12-16
| | | | | | | | | | | | | 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
* Allow labels in the '--aspects' parameter.Gravatar Dmitry Lomov2016-11-21
| | | | | -- MOS_MIGRATED_REVID=139573590
* Aspects-on-aspects implementation.Gravatar Dmitry Lomov2016-11-15
| | | | | -- MOS_MIGRATED_REVID=139189444
* Report cycles involving aspects correctly.Gravatar Lukacs Berki2016-06-14
| | | | | | | | | 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
* Split ActionMetadata into ActionAnalysisMetadata and ActionExecutionMetadata.Gravatar Rumou Duan2016-04-26
| | | | | | | Except in action execution logic (ActionExecutionFunction, SkyframeActionExecutor, etc.), switch Action interface references to either ActionAnalysisMetadata if possible or ActionExecutionMetadata. -- MOS_MIGRATED_REVID=120723431
* Remove Aspect field from AspectKey.Gravatar Dmitry Lomov2016-04-07
| | | | | -- MOS_MIGRATED_REVID=119141878
* Use the correct Aspect in AspectFunction for Skylark aspects.Gravatar Dmitry Lomov2016-04-07
| | | | | | | | | | | | | 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
* Use static creation method for SkyKey. This allows interning SkyKeys as they ↵Gravatar Janak Ramakrishnan2016-03-03
| | | | | | | 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
* Use two configurations for AspectKeys.Gravatar Michael Staib2016-03-01
| | | | | | | | | | | | 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
* Use Labels, rather than PathFragments, to represent Skylark loads ↵Gravatar John Field2015-11-13
| | | | | | | | | | | | | | | | | | | | | 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 terminology update.Gravatar Dmitry Lomov2015-11-10
| | | | | | | | Aspect => ConfiguredAspect AspectWithParameters => Aspect -- MOS_MIGRATED_REVID=107375211
* Parametrize aspect definition with AspectParameters.Gravatar Dmitry Lomov2015-11-02
| | | | | -- MOS_MIGRATED_REVID=106848269
* Implement propagation along dependencies for Skylark aspects.Gravatar Dmitry Lomov2015-11-02
| | | | | -- MOS_MIGRATED_REVID=106694515
* Introduce an AspectClass: a representation of a class of aspects.Gravatar Dmitry Lomov2015-10-22
| | | | | | | For native aspects, AspectClass is a facade for Class<AspectFactory<...>>. -- MOS_MIGRATED_REVID=105986390
* Improve error diagnostics for Skylark aspects.Gravatar Dmitry Lomov2015-10-20
| | | | | -- MOS_MIGRATED_REVID=105851371
* Implement aspect(...) Skylark function.Gravatar Dmitry Lomov2015-10-20
| | | | | -- MOS_MIGRATED_REVID=105844221
* Rollback of commit ac7195025b073948785db8c6975a53fc305c5087.Gravatar Peter Schmitt2015-10-20
| | | | | | | | | | | | | *** Reason for rollback *** Uses tests that don't run on Bazel *** Original change description *** Implement aspect(...) Skylark function. -- MOS_MIGRATED_REVID=105808850
* Implement aspect(...) Skylark function.Gravatar Dmitry Lomov2015-10-16
| | | | | -- MOS_MIGRATED_REVID=105596479
* Rationalize copyright headersGravatar Damien Martin-Guillerez2015-09-25
| | | | | | | | | | | 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
* Move Label from the lib.syntax to the lib.cmdline package so that:Gravatar Lukacs Berki2015-09-21
| | | | | | | | | | - 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
* Save information about transitive packages in ConfiguredTargetValue and ↵Gravatar Marian Lobur2015-09-09
| | | | | | | AspectValue. -- MOS_MIGRATED_REVID=102643564
* Aspects can get information from their base rule.Gravatar Marian Lobur2015-09-02
| | | | | -- MOS_MIGRATED_REVID=102126786
* A prototype implementation of top-level aspects.Gravatar Dmitry Lomov2015-08-20
| | | | | -- MOS_MIGRATED_REVID=101033236
* Remove BuildConfiguration.cacheKey() and replace .shortCacheKey() with a ↵Gravatar Lukacs Berki2015-06-29
| | | | | | | | | | | .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
* Update from Google.Gravatar Han-Wen Nienhuys2015-02-25
-- MOE_MIGRATED_REVID=85702957