aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/skyframe/AspectFunction.java
Commit message (Collapse)AuthorAge
* Add the capability to register a trimming RuleTransitionFactory.Gravatar mstaib2018-04-19
| | | | | | | | | | This RuleTransitionFactory will be applied to all targets after other transitions, and is intended to be used to manually trim the configuration based on tagging of that target. This is a stopgap feature until automatic trimming of configuration can be implemented. RELNOTES: None. PiperOrigin-RevId: 193573013
* Deprecate TransitiveInfoCollection#getConfiguration(), adding two new ↵Gravatar janakr2018-03-26
| | | | | | | | methods, TransitiveInfoCollection#getConfigurationKey() and ConfiguredTarget#getConfigurationChecksum(). These methods currently delegate to #getConfiguration(), but in the future they won't. I hope to get rid of #getConfigurationChecksum(), but I may have to fold the checksum into BuildConfigurationValue.Key or leave it as a separate field in ConfiguredTarget. Transform a representative (random?) selection of #getConfiguration calls, to show that it's pretty much possible everywhere. PiperOrigin-RevId: 190474978
* Adds hook to AspectFunction to allow for inlining SkylarkImportLookupFunction.Gravatar cpeyser2018-03-23
| | | | | | If inlining is off, fixes a bug where null return values resulted in an error. PiperOrigin-RevId: 190255818
* Add a DefaultBuildOptions specifying default build flags that may differ ↵Gravatar mjhalupka2018-03-22
| | | | | | from the provided defaults in Options classes. These are used to create BuildOptionsDiffForReconstruction, which lets us store only the diffs in our BuildConfigurationValue.Keys. PiperOrigin-RevId: 190117455
* Add BuildConfiguration to ConfiguredTargetAndTarget and rename it to ↵Gravatar janakr2018-03-10
| | | | | | ConfiguredTargetAndData. We want to get BuildConfiguration out of ConfiguredTarget because it uses >800K when serialized. PiperOrigin-RevId: 188600002
* Update ToolchainUtil to properly load and use the available executionGravatar John Cater2018-02-28
| | | | | | | | | platforms, and correctly merge together the results from TRF. Part of #4442. Change-Id: I31d83fa73a93d39a0e18d05a43a1c8666ac5a2d2 PiperOrigin-RevId: 187324257
* 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
* Start slimming down ToolchainResolutionKey: get rid of BuildConfiguration. ↵Gravatar janakr2018-02-14
| | | | | | The real blocker is PlatformInfo, which is coming. PiperOrigin-RevId: 185742130
* 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
* Remove ConfiguredTarget.getTarget() from AspectFunction and replace it with aGravatar mjhalupka2018-01-25
| | | | | | ConfiguredTargetAndTarget.getTarget(). PiperOrigin-RevId: 183241259
* 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
* Start the process of getting Target out of ConfiguredTarget: add a new ↵Gravatar janakr2018-01-18
| | | | | | | | | | | | container, ConfiguredTargetAndTarget, that can be used to access Targets, and deprecate ConfiguredTarget#getTarget. ConfiguredAndTargetObjects are intended to be limited in scope, not being persisted to Skyframe. The eventual plan is to remove the target field from ConfiguredTarget. This CL is mostly straightforward, except for dealing with AliasConfiguredTargets, which cause some complications. A significant cleanup is still needed before #getTarget can be removed, but I don't see any impossible blockers. We will may still need to store a Target-like object in ConfiguredTarget (that has the RuleClass, or at least a string representation of it, for instance), but that will let us avoid storing a full Target together with its associated Package. PiperOrigin-RevId: 182371566
* 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
* Expose ObjcProtoAspect to Skylark.Gravatar cparsons2017-12-20
| | | | | RELNOTES: None. PiperOrigin-RevId: 179737025
* 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
* Replace all usages of Blaze's Preconditions class with guava.Gravatar tomlu2017-11-09
| | | | | | | | Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own. This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually. PiperOrigin-RevId: 175033526
* Add memory profiler.Gravatar tomlu2017-10-18
| | | | | | | | | | | This adds two dump command, bazel dump --rules and bazel dump --skylark_memory. dump --rules outputs a summary of the count, action count, and memory consumption of each rule and aspect class. dump --skylark_memory outputs a pprof-compatible file with all Skylark analysis allocations. Users can then use pprof as per normal to analyse their builds. RELNOTES: Add memory profiler. PiperOrigin-RevId: 172558600
* Move aspect resolution out of ConfiguredTargetFunction.Gravatar gregce2017-09-21
| | | | | | Part of the effort to simplify ConfiguredTargetFunction. PiperOrigin-RevId: 169453435
* Project reorg: move *ConfiguredTarget to new configuredtargets/ pathGravatar gregce2017-09-18
| | | | | | | Exempt RuleConfiguredTarget in this change because that's liable to touch a billion files. PiperOrigin-RevId: 168929827
* Remove outdated references to static vs. dynamic configurations.Gravatar gregce2017-09-13
| | | | PiperOrigin-RevId: 168452997
* Rule classes cannot request duplicate toolchains.Gravatar cpeyser2017-09-08
| | | | PiperOrigin-RevId: 167861778
* Move RuleConfiguredTargetFactory to lib.analysisGravatar ulfjack2017-08-07
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164446955
* Move AliasProvider to lib.analysisGravatar ulfjack2017-08-07
| | | | | | | This is part of splitting up the build-base library into separate libraries for analysis, exec, and rules. PiperOrigin-RevId: 164438390
* Improve error message when requesting an invalid toolchain type from the ↵Gravatar John Cater2017-08-01
| | | | | | | | | context. Fixes #3428. Change-Id: Ib3f45bc6856651cfb29d338d0b4480ba1dd77cea PiperOrigin-RevId: 163760940
* Make error message in case top-level aspect is missing clearer.Gravatar Dmitry Lomov2017-07-24
| | | | | | | Fixes #2874. Change-Id: I636e0f6b56a1e33adfc64e90f36f76d4254d0281 PiperOrigin-RevId: 162726099
* Use toolchain resolution in rule creation.Gravatar John Cater2017-07-21
| | | | | | | Part of #2219. Change-Id: Id4929d5ddcd57b4635af5e513eb9a09f16a78e71 PiperOrigin-RevId: 162634398
* Clean up API for the Extension classGravatar brandjon2017-05-09
| | | | | RELNOTES: None PiperOrigin-RevId: 155507750
* Do not report errors when aspects try to attach to files.Gravatar dslomov2017-05-08
| | | | | | | | | | | Instead, silently ignore them in the same way we do for rules to which aspects are not applicable. In the future aspects will gain the ability to apply to, and propagate through, files. RELNOTES: None. PiperOrigin-RevId: 155369925
* Native aspects can opt-in to apply to files.Gravatar dslomov2017-04-25
| | | | | | | Only works for top-level targets. RELNOTES: None. PiperOrigin-RevId: 154176914
* Aspect propagation should not lose transitively-visible aspects.Gravatar dslomov2017-04-11
| | | | | | | | If aspect a3 sees aspect a2, and aspect a2 sees aspect a1, propagation of the aspect list [a1,a2,a3] should not lose any aspects. RELNOTES: None. PiperOrigin-RevId: 152786900
* 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
* Do not execute aspect implementation if target advertizes but fails to ↵Gravatar Dmitry Lomov2017-03-01
| | | | | | | | | | | provide a provider. Previously we always executed the function, but didn't add the aspect to the deps. -- PiperOrigin-RevId: 148887089 MOS_MIGRATED_REVID=148887089
* Report inconsistent aspect order error to the user.Gravatar Dmitry Lomov2017-02-24
| | | | | | -- PiperOrigin-RevId: 148342788 MOS_MIGRATED_REVID=148342788
* 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
* Aspects-on-aspects implementation.Gravatar Dmitry Lomov2016-11-15
| | | | | -- MOS_MIGRATED_REVID=139189444
* Do not crash when aspects provide duplicate things.Gravatar Dmitry Lomov2016-11-11
| | | | | -- MOS_MIGRATED_REVID=138860974
* Enable aspect invocations to be matched by output filters.Gravatar Michael Staib2016-09-19
| | | | | | | | | | | | | Currently aspects have no tag, i.e., they don't get checked against output filters at all. This changes aspects to have a tag of the same form as the rule they are attached to (i.e., the label of the target). Since the default output filters match on ^//package[:/], this should cover most uses of the output filter, while still allowing for finer control for those who crave it. -- MOS_MIGRATED_REVID=133425215
* Make aspects attached to aliases work when their actual= attribute is a select.Gravatar Lukacs Berki2016-08-31
| | | | | | | Fixes https://github.com/bazelbuild/e4b/issues/6 . -- MOS_MIGRATED_REVID=131698950
* Allow Skyframe graph lookups and value retrievals to throw InterruptedException.Gravatar Janak Ramakrishnan2016-08-16
| | | | | | | The only place we now don't handle InterruptedException is in the action graph created after analysis, since I'm not sure that will be around for that much longer. -- MOS_MIGRATED_REVID=130327770
* Changes DependencyResolver <Attribute, Dep> map from a ListMultimap to new classGravatar Greg Estren2016-08-12
| | | | | | | | | | | | | | | | | | | | | | OrderedSetMultimap. This maintains insertion order while eliminating duplicates. Certain rules, in particular, otherwise break this invariant: https://github.com/bazelbuild/bazel/blo[]e3e28274cca5b87f48abe33884edb84016dd3/src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetFunction.java#L403 There's no reason (to my knowledge) to need multiple instances of the same <Attribute, Dependency> pair. More context from Google code review: (Michael Staib): > There are many things which pass around a dependentNodeMap or help construct one or modify one. We want an interface which has the right guarantees. > ListMultimap is not the right interface because it has no guarantee of unique elements, which we want - we don't want the problem that this CL ran into, and there's no reason (that we know of, to be confirmed) that anyone would want multiple identical Dependencies. > SetMultimap is not the right interface because it has no guarantee of deterministic iteration order or efficient iteration, which we want - dependency order sometimes matters (e.g., Java classpath or C++ link order). > We agreed that the best way to get what we want is to define our own interface with its own simultaneous uniqueness and iterability guarantees. Unspoken in the discussion was why we wouldn't just use LinkedHashMultimap as the thing we pass around. IMO the reason for that is that we don't care that it be a LinkedHashMultimap specifically; if tomorrow Guava comes out with a faster cooler map that has deterministic and efficient iteration and guarantees element uniqueness, we want it. > In this case we're going to make the "interface" be a (final?) class: OrderedSetMultimap, an extension of ForwardingSetMultimap which delegates to LinkedHashMultimap, an implementation which does support both of those guarantees. > I had mentioned in the conversation that none of the Multimap implementations make guarantees about key iteration order, but this is not true - LinkedHashMultimap preserves key insertion order. We should perhaps declare this as part of the OrderedSetMultimap contract as well. -- MOS_MIGRATED_REVID=130037643
* Add an overview comment about how the analysis phase works and some pointers ↵Gravatar Lukacs Berki2016-05-19
| | | | | | | to it. -- MOS_MIGRATED_REVID=122718503
* Print an error message when the wrong type of input is given as an aspectGravatar Kristina Chodorow2016-05-11
| | | | | | | | | And add a test. Another issue I found while attempting to reproduce #1228, but not actually a fix for that bug. -- MOS_MIGRATED_REVID=121998625
* Add an "alias" rule.Gravatar Lukacs Berki2016-05-10
| | | | | | | This will be used to replace RedirectChaser so that we don't need to load packages during configuration creation anymore. -- MOS_MIGRATED_REVID=121935989
* Expose parameterized aspects to Skylark.Gravatar Googler2016-05-09
| | | | | | | | | | | | | | | 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
* Delete the interface NativeAspectFactory and make native aspects extend from ↵Gravatar Luis Fernando Pino Duque2016-04-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NativeAspectClass. This a large refactoring of the aspects, currently we have the following: - AspectClasses: The interface AspectClass is a implemented by either SkylarkAspectClass or NativeAspectClass<NativeAspectFactory>. They are wrappers for the AspectFactories and they hold the information about the Class<> of the factory. - AspectFactories (FooAspect.java): Represented by the interfaces ConfiguredAspectFactory and NativeAspectFactory, also by the interface ConfiguredNativeAspectFactory which is the union of the two aforementioned interfaces. All aspects implement ConfiguredNativeAspectFactory except Skylark aspects which implement only ConfiguredAspectFactory. After this CL the distinction between NativeAspectFactories and NativeAspectClasses dissappear, namely aspect that extends NativeAspectClass is considered native and if it implements ConfiguredAspectFactory it is configured. Therefore the interfaces NativeAspectFactory and ConfiguredNativeAspectFactory both disappear. With this refactoring the aspectFactoryMap in the ConfiguredRuleClassProvider changes its type from (String -> Class<? extends NativeAspectClass>) to (String -> NativeAspectClass) which means it is now able to have an instance of the aspect instead of its Class only. By doing this, it is now possible to pass parameters when creating an aspect in the ConfiguredRuleClassProvider. -- MOS_MIGRATED_REVID=120819647
* 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
* Make aspects work through bind(). Gravatar Lukacs Berki2016-04-22
| | | | | | | | | | | bind() is assumed to be able to provide any provider. This is suboptimal, but beats the alternative of traversing the dependency graph to an arbitrary depth. The reason for the removal of the iteration ability in TransitiveInfoCollection is that now aspects can be attached to BindConfiguredTarget, too, which is not a RuleConfiguredTarget. Whereas I could have implemented the iterator, it was used only in BindConfiguredTarget anyway, so there didn't seem to be much reason to. Some work towards #952. -- MOS_MIGRATED_REVID=120549877
* Remove SkylarkAspectClass.getDefintion.Gravatar Dmitry Lomov2016-04-07
| | | | | -- MOS_MIGRATED_REVID=119162307
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-31 12:48:11 +0000