aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/analysis/MergedConfiguredTarget.java
Commit message (Collapse)AuthorAge
* Optimize TransitiveInfoMap memory consumption.Gravatar Googler2017-05-09
| | | | | | Instead of using ImmutableMap, we share the keys between all provider maps with an identical key set. PiperOrigin-RevId: 155432135
* Make TransitiveInfoMap interface narrower.Gravatar Googler2017-05-05
| | | | | | This constrains implementations less, allowing for greater freedom when optimizing. PiperOrigin-RevId: 155203001
* Make TransitiveInfoProviderMap an interface.Gravatar Googler2017-05-04
| | | | PiperOrigin-RevId: 155125357
* Do not add SkylarkProviders to target's provider map unless it is needed.Gravatar dslomov2017-05-03
| | | | | RELNOTES: None. PiperOrigin-RevId: 154943665
* Do not put OutputGroupProvider into SkylarkProviders.Gravatar dslomov2017-05-03
| | | | | | | | | Almost every target has an OutputGroupProvider. Putting an ("output_groups", value) pair into SkylarkProviders creates an unneccessary map. This CL removes it. RELNOTES: None. PiperOrigin-RevId: 154940624
* Remove memory regression introduced with OutputGroupInfo provider.Gravatar dslomov2017-05-03
| | | | | | | | Almost every target has an OutputGroupProvider. Do not create another Key->Provider map just for it. RELNOTES: None. PiperOrigin-RevId: 154937690
* Implement OutputGroupInfo provider.Gravatar dslomov2017-05-03
| | | | | | | Work towards #2894. RELNOTES: None. PiperOrigin-RevId: 154829065
* Fix memory regression introduced by default providersGravatar vladmos2017-04-13
| | | | | | | The memory regression was introduced in https://github.com/bazelbuild/bazel/commit/360fb4d9a1e2c44154b17aeb866e07bac2dd1b5b , now default providers are optimized and are built only on demand for all types of targets. PiperOrigin-RevId: 152957220
* Fix dir() on Targets with aspects applied.Gravatar Dmitry Lomov2017-03-22
| | | | | | -- PiperOrigin-RevId: 150869561 MOS_MIGRATED_REVID=150869561
* Refactor implementation of native and Skylark declared providers.Gravatar Dmitry Lomov2017-03-03
| | | | | | | | | | | | 1) Instead of having a single class for both, split them into {Skylark,Native}ClassObjectConstructors 2) Allow NativeClassObjectConstructors to customize their instantiation logic. 3) Prepare ClassObjectConstructor.Key to be serializable. -- PiperOrigin-RevId: 148997553 MOS_MIGRATED_REVID=148997553
* Remove ctx.aspect_id and Target.aspect_ids.Gravatar Dmitry Lomov2017-02-23
| | | | | | -- PiperOrigin-RevId: 148322874 MOS_MIGRATED_REVID=148322874
* 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
* Add 'aspect_id' for to identify aspects that has been applied to the target.Gravatar Dmitry Lomov2016-12-05
| | | | | | | | | | | | | | | | | | | Add a concept of aspect_id: an unique string that identifies a propagating aspect (aspect class + parameters). This string is designed to be: - Unique for each aspect - human-readable for debugging purposes - not easily parsable. Skylark API: - `ctx.aspect_id` returns an identifier of the current aspect inside aspect implementation function - `Target.aspect_ids` return a list of aspect ids for aspects applied to a given Target (https://www.bazel.io/versions/master/docs/skylark/lib/Target.html) -- PiperOrigin-RevId: 141057865 MOS_MIGRATED_REVID=141057865
* Provide AspectDescriptor to ConfiguredAspect.Gravatar Dmitry Lomov2016-11-29
| | | | | | | | Also clean up the setting of aspect name in ConfiguredAspect and AspectDefintion - it is now obtained from the AspectClass. -- MOS_MIGRATED_REVID=140357052
* Implement 'output_groups' provider.Gravatar Dmitry Lomov2016-11-21
| | | | | | | | | | This behavior - that 'output_groups' is a provider available on targets and aspects - has been accidental, but people already depend on it. This CL keeps that behavior, while fixing the bug that two aspects could not both provide output groups. -- MOS_MIGRATED_REVID=139578378
* Do not crash when aspects provide duplicate things.Gravatar Dmitry Lomov2016-11-11
| | | | | -- MOS_MIGRATED_REVID=138860974
* Remove unneeded annotationGravatar Jon Brandvein2016-10-12
| | | | | | | | It was a temporary workaround due to client Skylark code that was sensitive to type(). That code has been fixed. -- MOS_MIGRATED_REVID=135920620
* Make EvalUtils.getDataTypeNameFromClass() look for @SkylarkModules in parent ↵Gravatar Jon Brandvein2016-10-12
| | | | | | | | | classes This is needed to let subclasses of @SkylarkModules have the same type() string as their superclass, without requiring a second annotation for the subclass. -- MOS_MIGRATED_REVID=135814343
* Change allowedRuleClasses/mandatoryProviders semantics to "either-or" ↵Gravatar Dmitry Lomov2016-10-07
| | | | | | | | | | instead of "and". Also allow native rules to require declared providers on their dependencies. -- MOS_MIGRATED_REVID=135454750
* Add a specialized TransitiveInfoProviderMap to map TransitiveInfoProviders ↵Gravatar Googler2016-09-19
| | | | | | | | | | | | by class. TransitiveInfoProviderMap enforces that the provider implements the interface it's keyed by and provides accessors the reduce the amount of casting. This in general reduces boilerplate throughout wherever TransitiveInfoProviders are mapped by their class. Also add shorthand for adding a provider where it only implements TransitiveInfoProvider once, reducing the redundant specification of the TransitiveInfoProvider class. Infer the class as the exclusive direct implementor of TransitiveInfoProvider to account for special cases like AutoValue and LicenseProvider. -- MOS_MIGRATED_REVID=133386336
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 16:50:08 +0000