aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/packages/AspectDefinition.java
Commit message (Collapse)AuthorAge
* Allow declared providers in attribute and aspect defintions.Gravatar Dmitry Lomov2017-03-06
| | | | | | -- PiperOrigin-RevId: 149169656 MOS_MIGRATED_REVID=149169656
* Restrict aspects visible to other aspects according to their advertised ↵Gravatar Dmitry Lomov2017-02-15
| | | | | | | | providers. -- PiperOrigin-RevId: 147526961 MOS_MIGRATED_REVID=147526961
* Refactoring: Types report what class of labels they contain.Gravatar Michael Staib2017-02-14
| | | | | | | | | | | | | | | | | | | | | Currently label-type attributes are detected in many places across the codebase by simply reference-comparing against each of the label types. This CL aims to generalize most of these cases, moving the encoding of this logic into a single place (Type/BuildType itself). Not all of these cases can be made general without further refactoring, and some perhaps shouldn't be - serialization and Skylark rule context, for example, need to do exotic things based on the type. But most sites can avoid having to enumerate all the types they work with explicitly. This causes LABEL_DICT_UNARY to start being treated like the other label types, which means that CcToolchainSuiteRule and JavaRuntimeSuiteRule need to include a set of allowed file types (none, in their case). Skylark will continue treating it as a dictionary from String to Label in its rule context, however, to avoid visible behavior changes. -- PiperOrigin-RevId: 147471542 MOS_MIGRATED_REVID=147471542
* Rollback of commit cdbad585187dfe7bbb4d69ad68a1baf852beb691.Gravatar Michael Staib2017-02-14
| | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Breaks Skylark aspects running over rules with LABEL_DICT_UNARY attributes. *** Original change description *** Refactoring: Types report what class of labels they contain. Currently label-type attributes are detected in many places across the codebase by simply reference-comparing against each of the label types. This CL aims to generalize most of these cases, moving the encoding of this logic into a single place (Type/BuildType itself). Not all of these cases can be made general without further refactoring, and some perhaps shouldn't be - serialization and Skylark rule context, for example, need to do... -- PiperOrigin-RevId: 147385072 MOS_MIGRATED_REVID=147385072
* Add an algorithm to reduce aspect paths according to aspects' visibility to ↵Gravatar Dmitry Lomov2017-02-14
| | | | | | | | | | | | each other. Aspects negotiate their visibility by advertizing and requiring providers. The algorithm is not used yet (that is future work). -- PiperOrigin-RevId: 147354682 MOS_MIGRATED_REVID=147354682
* Refactoring: Types report what class of labels they contain.Gravatar Michael Staib2017-02-13
| | | | | | | | | | | | | | | | | | | Currently label-type attributes are detected in many places across the codebase by simply reference-comparing against each of the label types. This CL aims to generalize most of these cases, moving the encoding of this logic into a single place (Type/BuildType itself). Not all of these cases can be made general without further refactoring, and some perhaps shouldn't be - serialization and Skylark rule context, for example, need to do exotic things based on the type. But most sites can avoid having to enumerate all the types they work with explicitly. This causes LABEL_DICT_UNARY to start being treated like the other label types, which means that CcToolchainSuiteRule and JavaRuntimeSuiteRule need to include a set of allowed file types (none, in their case). -- PiperOrigin-RevId: 147175424 MOS_MIGRATED_REVID=147175424
* Allow aspects to adveritise providers they provide.Gravatar Dmitry Lomov2017-02-07
| | | | | | -- PiperOrigin-RevId: 146794883 MOS_MIGRATED_REVID=146794883
* Remove the ability for an aspect to propagate a different aspect.Gravatar Dmitry Lomov2017-01-20
| | | | | | | | | This functionality is never used, have never been exposed to Skylark and is a continuous pain to maintain and test. -- PiperOrigin-RevId: 145079832 MOS_MIGRATED_REVID=145079832
* Add ability to specify required aspect providers for aspects.Gravatar Dmitry Lomov2017-01-17
| | | | | | | | It is just a specification yet, it does nothing. -- PiperOrigin-RevId: 144687428 MOS_MIGRATED_REVID=144687428
* Encapsulate the required provider logic in RequiredProviders class.Gravatar Dmitry Lomov2017-01-10
| | | | | | | | | For now, only for aspects, but eventually expand to Attribute's mandatory providers as well. -- PiperOrigin-RevId: 144063369 MOS_MIGRATED_REVID=144063369
* Extract a set of advertised providers into a separate class.Gravatar Dmitry Lomov2017-01-10
| | | | | | -- PiperOrigin-RevId: 143991903 MOS_MIGRATED_REVID=143991903
* Global cleanup change.Gravatar Googler2016-12-07
| | | | | | -- PiperOrigin-RevId: 141307853 MOS_MIGRATED_REVID=141307853
* 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
* Allow aspects to specify multiple sets of required providers to match ↵Gravatar Rumou Duan2016-12-01
| | | | | | | against rules. Aspects can attach to a rule if at least one set of required providers are present on the rule. -- MOS_MIGRATED_REVID=140605023
* 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
* Make query return dependencies contributed by aspects on rules that don't ↵Gravatar Lukacs Berki2016-10-18
| | | | | | | advertise and providers. -- MOS_MIGRATED_REVID=136452596
* Allow aspects to propagate to all attributes.Gravatar Dmitry Lomov2016-09-27
| | | | | -- MOS_MIGRATED_REVID=134378592
* Fix hypothetical crash bug in AspectDefinition#addAllAttributesOfAspect when ↵Gravatar Nathan Harmata2016-06-16
| | | | | | | the default value of a parameterized aspect attribute is null. This is hypothetical because I couldn't figure out an end-to-end way to tickle the bug. Still, the surrounding code is very brittle and things may change in the future such that the bug is trivially tickle-able. -- MOS_MIGRATED_REVID=124977450
* Always restrict aspects to only access requested configuration fragments.Gravatar Michael Staib2016-05-19
| | | | | | | | | | | This completes the introduction of aspect configuration fragment enforcement for static configuration builds; as of this change, it is no longer possible to fall back to the base rule's set of requested configuration fragments. This sort of fallback may become possible later, likely in a more controlled way. -- MOS_MIGRATED_REVID=122638152
* 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
* 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
* Don't keep packages in the default repository around after loading.Gravatar Brian Silverman2016-03-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, this would get thrown when referring to the same package from both the main and default repositories: java.lang.IllegalArgumentException: Multiple entries with same key: tools/cpp=/home/brian/971-Robot-Code and tools/cpp=/home/brian/971-Robot-Code at com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:136) at com.google.common.collect.RegularImmutableMap.checkNoConflictInKeyBucket(RegularImmutableMap.java:98) at com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:84) at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:295) at com.google.devtools.build.lib.buildtool.BuildTool.transformPackageRoots(BuildTool.java:301) at com.google.devtools.build.lib.buildtool.BuildTool.buildTargets(BuildTool.java:209) at com.google.devtools.build.lib.buildtool.BuildTool.processRequest(BuildTool.java:334) at com.google.devtools.build.lib.runtime.commands.TestCommand.doTest(TestCommand.java:119) at com.google.devtools.build.lib.runtime.commands.TestCommand.exec(TestCommand.java:104) at com.google.devtools.build.lib.runtime.BlazeCommandDispatcher.exec(BlazeCommandDispatcher.java:371) at com.google.devtools.build.lib.runtime.BlazeRuntime$3.exec(BlazeRuntime.java:1016) at com.google.devtools.build.lib.server.RPCService.executeRequest(RPCService.java:65) at com.google.devtools.build.lib.server.RPCServer.executeRequest(RPCServer.java:434) at com.google.devtools.build.lib.server.RPCServer.serve(RPCServer.java:229) at com.google.devtools.build.lib.runtime.BlazeRuntime.serverMain(BlazeRuntime.java:975) at com.google.devtools.build.lib.runtime.BlazeRuntime.main(BlazeRuntime.java:772) at com.google.devtools.build.lib.bazel.BazelMain.main(BazelMain.java:55) And this would get thrown for any packages in the main repository loaded from other repositories: java.lang.RuntimeException: Unrecoverable error while evaluating node 'PACKAGE:@//tools/build_rules/go/toolchain' (requested by nodes ) at com.google.devtools.build.skyframe.ParallelEvaluator$Evaluate.run(ParallelEvaluator.java:982) at com.google.devtools.build.lib.concurrent.AbstractQueueVisitor$WrappedRunnable.run(AbstractQueueVisitor.java:499) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.IllegalArgumentException: Invalid BUILD file name for package '@//tools/build_rules/go/toolchain': /home/brian/bazel/tools/build_rules/go/toolchain/BUILD at com.google.devtools.build.lib.packages.Package.finishInit(Package.java:299) at com.google.devtools.build.lib.packages.Package$Builder.finishBuild(Package.java:1308) at com.google.devtools.build.lib.skyframe.PackageFunction.compute(PackageFunction.java:501) at com.google.devtools.build.skyframe.ParallelEvaluator$Evaluate.run(ParallelEvaluator.java:933) ... 4 more Sponsor's comment: note the abundance of new Label.resolveRepositoryRelative() calls. They are ugly, but it's only making existing ugliness explicit. Yes, we should fix it, especially in the implementation of configurable attributes. Refs #940 -- Change-Id: I8bd7f7b00bec58a7157507595421bc50c81b404c Reviewed-on: https://bazel-review.googlesource.com/#/c/2591 MOS_MIGRATED_REVID=117429733
* Properly filter out Aspect attributes when `blaze query` requests ↵Gravatar Dmitry Lomov2016-01-22
| | | | | | | | | --noimplicit_deps and/or --nohost_deps. RELNOTES: --noimplicit_deps and --nohost_deps work correctly for Aspect attributes. -- MOS_MIGRATED_REVID=112724917
* Extract AttributeInfoProvider interface for DependencyFilters.Gravatar Dmitry Lomov2016-01-22
| | | | | | | | This is in preparation of implementing dependency filtering correctly for aspects. -- MOS_MIGRATED_REVID=112721440
* Refactor dependency filtering out of Rule class.Gravatar Dmitry Lomov2016-01-22
| | | | | -- MOS_MIGRATED_REVID=112717648
* Enable Aspects to specify their configuration fragment dependencies.Gravatar Michael Staib2016-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note: This specification currently does not have any effect, but soon... In the default mode, when an aspect does not call any of the configuration fragment methods on its AspectDefinition.Builder, the old behavior will persist; aspects can only access fragments their associated rule has access to, and have no guarantee as to what those fragments are. This mode will become deprecated with a future CL. If an aspect does call a configuration fragment method, it will have a configuration fragment policy. In a future CL, this will mean it will be restricted to accessing only those fragments, but will be understood as requiring access to them for the purposes of dynamic configuration, even if the rule it is attached to or created by does not otherwise require them. Eventually, all aspects will be required to declare their configuration fragments this way. Skylark aspects may also declare configuration fragments as of this CL. Two new parameters are added to the aspect() function, fragments and host_fragments, mirroring the similar parameters for rules. If both of these parameters are empty or unspecified, the default mode is used, as with normal aspects. Also in this CL: * Minor javadoc fixes for AspectDefinition. * Additional tests for AspectDefinition. -- MOS_MIGRATED_REVID=112271713
* Implement aspect attributes and expose them to aspect implementation function.Gravatar Dmitry Lomov2015-12-16
| | | | | -- MOS_MIGRATED_REVID=110356954
* Use Bazel Preconditions variant which avoids varargs array creationGravatar Mark Schaller2015-12-10
| | | | | | | Reduces garbage. -- MOS_MIGRATED_REVID=109914243
* Support skylark aspects in serialization/deserialization.Gravatar Dmitry Lomov2015-11-30
| | | | | -- MOS_MIGRATED_REVID=108964575
* 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
* Clean up Aspect checks in query tests.Gravatar Eric Fellheimer2015-09-28
| | | | | -- MOS_MIGRATED_REVID=103977080
* 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
* Separate build-specific types and types inherent to Skylark.Gravatar Lukacs Berki2015-09-21
| | | | | -- MOS_MIGRATED_REVID=103374106
* Annotate AspectDefinition.attributeAspect @SafeVarargs to suppress warnings.Gravatar Ulf Adams2015-08-05
| | | | | -- MOS_MIGRATED_REVID=99904596
* Description redacted.Gravatar Lukacs Berki2015-06-10
| | | | | -- MOS_MIGRATED_REVID=95615442
* Description redacted.Gravatar Rumou Duan2015-06-05
| | | | | -- MOS_MIGRATED_REVID=95135804
* Add support of aspects to the skyframe implementation of query. To keep ↵Gravatar Marian Lobur2015-03-25
| | | | | | | these two versions of query consistent we need to add additional edges to the target that contains aspects, instead of adding it to the target that was in direct deps of the original one. -- MOS_MIGRATED_REVID=89483301
* Update from Google.Gravatar Han-Wen Nienhuys2015-02-25
-- MOE_MIGRATED_REVID=85702957
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-14 17:35:42 +0000