aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/skyframe/ToplevelSkylarkAspectFunction.java
Commit message (Collapse)AuthorAge
* 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
* Fix: return an error from the analysis phase with keep_going in error cases.Gravatar Ulf Adams2016-01-27
| | | | | | | | | | | - if there are failed top-level aspects - if there are conflicting actions I ended up rewriting how errors are signaled from the SkyframeBuildView. I think this is safe, but please review carefully. -- MOS_MIGRATED_REVID=113150100
* Share some error handling code between aspects and top-level aspects.Gravatar Ulf Adams2016-01-25
| | | | | -- MOS_MIGRATED_REVID=112948493
* Fix a couple of bugs related to error handling for top-level aspects.Gravatar Ulf Adams2016-01-20
| | | | | -- MOS_MIGRATED_REVID=112561390
* General cleanup for the configured target / aspect creation code.Gravatar Ulf Adams2016-01-19
| | | | | | | | | | | | | | - update some comments - add some comments to make it easier to follow - delete some dead code, in particular the SkyframeDependencyResolver can never be null; remove an non-applicable @Nullable annotation I'm trying to figure out how the error handling code works, in order to add support for interleaved loading+analysis, which requires handling loading errors in this code path. -- MOS_MIGRATED_REVID=112456674
* Support skylark aspects in serialization/deserialization.Gravatar Dmitry Lomov2015-11-30
| | | | | -- MOS_MIGRATED_REVID=108964575
* 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
* Implement propagation along dependencies for Skylark aspects.Gravatar Dmitry Lomov2015-11-02
-- MOS_MIGRATED_REVID=106694515