| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
We now track Causes instead of plain Labels, which will allow us to do better reporting in the future. Add basic tests.
PiperOrigin-RevId: 198380468
|
| |
|
|
|
|
| |
If inlining is off, fixes a bug where null return values resulted in an error.
PiperOrigin-RevId: 190255818
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are no syntactic changes within Skylark; the only difference is that aspects may have non-implicit attributes, so long as they have type 'string' and use the 'values' restriction. Such aspects may only be requested by rules which have attributes with types and names matching the non-implicit, non-defaulted attributes of the aspect.
This is not yet a complete match for native AspectParameters functionality since implicit attributes cannot yet be affected by attribute values, but that will be added later.
Implicit aspects are still required to have default values. Non-implicit aspect attributes are considered "required" unless they have a default value. An error will occur if they are applied to a rule that does not "cover" all required attributes by having attributes of matching name and type. While non-implicit aspect attributes with a default are not required, they will still take on the value of a rule attribute with the same name and type if it is present.
Aspects with non-implicit, non-defaulted ("required") attributes cannot be requested on the command line, only by a rule.
RELNOTES: Expose parameterized aspects to Skylark.
--
MOS_MIGRATED_REVID=121711715
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=112948493
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=112561390
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=108964575
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
--
MOS_MIGRATED_REVID=106694515
|
ulfjack
cpeyser
janakr
Dmitry Lomov
Googler
Michael Staib
John Field