aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/packages/Attribute.java
Commit message (Collapse)AuthorAge
* Rollback of commit 4381a1d6e8f711957f430aac0c301acec6dfa0eb.Gravatar Damien Martin-Guillerez2016-09-14
| | | | | | | | | | | | | *** Reason for rollback *** Breaks all projects using Bazel, see https://ci.bazel.io *** Original change description *** Deprecated and removed HOST_CFG and DATA_CFG global variables. -- MOS_MIGRATED_REVID=133005398
* Global cleanup change.Gravatar Vladimir Moskva2016-09-13
| | | | | -- MOS_MIGRATED_REVID=132976702
* Allow list of lists of mandatory native providersGravatar Googler2016-09-08
| | | | | -- MOS_MIGRATED_REVID=132464865
* Skylark no longer crashes when the default value of an attribute is a label ↵Gravatar Florian Weikert2016-09-06
| | | | | | | | | string that points to a remote repository. Fixes #1442. -- MOS_MIGRATED_REVID=132320130
* Roll forward of commit 19db71413329da3f5d22b5fc7681471f3d971d88 (Skylark: ↵Gravatar Florian Weikert2016-09-06
| | | | | | | | | | | | | Replaced late bound attributes with computed default attributes) with two bug fixes: 1. Unlike SkylarkComputedDefault, SkylarkComputedDefaultTemplate did not sort the names of its attribute dependencies. Consequently, lookup operations failed when callback functions in bzl files specified the names of their required attributes in a non-alphabetical order since the order of the key tuples was different (e.g. [1, 2] vs [2, 1]). It would be less error prone to always sort the dependencies in createDependencyAssignmentTuple(), but this would impact performance. 2. SkylarkCallbackFunction ignores the legacy "cfg" parameter in callback functions. This special case should be deleted once all cfg parameters have been removed from the depot. -- MOS_MIGRATED_REVID=132235927
* Rollback of commit 19db71413329da3f5d22b5fc7681471f3d971d88.Gravatar Tobias Werth2016-09-06
| | | | | -- MOS_MIGRATED_REVID=132058819
* Skylark: Replaced late bound attributes with computed default attributesGravatar Mark Schaller2016-09-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Motivation: Compared to computed default attributes, late bound attributes are evaluated in a later phase (analysis instead of loading phase). While both mechanisms provide access to other attributes of a rule, only late bound attributes additionally provide access to the build configuration. However, late bound attributes could be used to return new labels that have not been loaded before. Since this happens in the analysis phase, it can break one of Blaze's underlying principles, thus introducing a serious correctness bug. We decided to replace late bound attributes in Skylark with computed default attributes since this moves the evaluation of values into the loading phase, thus fixing this bug. Moreover, none of the existing users of this mechanism required access to the build configuration, which means that the user impact of this change is minimal. Implementation details: Unlike attributes of non-Skylark rules, however, Skylark computed defaults need to be able to depend on more than two configurable attributes since all attributes of Skylark rules are configurable by default. This has two implications: 1. Unlike "normal" Skylark attributes, Skylark computed defaults need to know about the existence of other attributes in order to declare a dependency on them. This CL takes advantage of work previously done to require parameter names to be the names of attributes used by the computed default function. 2. Since Bazel computes the combinations of all possible attribute values, a Skylark rule with a computed default that depends on a lot of configurable attributes could crash Bazel. Consequently, this CL also introduces an upper bound (64) for the number of valid combinations. Caveats: 1. Getting the depended-on attributes' names from function paramters is mildly surprising. Alternatives: The best solution would be to keep SkylarkLateBound, but restrict it in a way that it can only return already loaded labels. This is not possible right now. -- MOS_MIGRATED_REVID=131967238
* Add SkylarkClassObjectConstructor - a future return value of "provider" ↵Gravatar Dmitry Lomov2016-08-09
| | | | | | | function. -- MOS_MIGRATED_REVID=129726780
* Implements dynamic split transitions (minus latebound attribute splits).Gravatar Greg Estren2016-08-08
| | | | | | | | | | With the prereq work behind this, this is surprisingly straightforward. The main change is to eliminate BuildConfiguration.SplittableTransitionApplier, make both DynamicTransitionApplier and StaticTransitionApplier split-aware, and add awareness of this to ConfiguredTargetFunction.trimConfigurations. Latebound splits will follow next. -- MOS_MIGRATED_REVID=129480309
* Make SkylarkClassObject "Bazel-specific".Gravatar Dmitry Lomov2016-08-05
| | | | | | | This in preparation to DeclaredProviders implementation. -- MOS_MIGRATED_REVID=129420617
* Allow objc rule deps to include any rule that exports an "objc" provider.Gravatar Googler2016-08-01
| | | | | | | | | | | This change was motivated by a need to write pure Skylark rules that expose their own objc providers so they can be used as deps to other libraries/application targets (e.g., SceneKit/SpriteKit compiled resources, []) without having to whitelist them and wait for a Blaze release. This CL fixes what seems to be a bug in validateRuleDependency, where the behavior in the doc comment implies that it will accept a whitelisted rule name *or* a list of mandatory providers, but as implemented today it seems to require the rule to be whitelisted even if the mandatory native providers matched. RELNOTES: objc_* rules can now depend on any target that returns an "objc" provider. -- MOS_MIGRATED_REVID=128835096
* Clean up DependencyResolver's interface for the dynamic config migration and ↵Gravatar Greg Estren2016-07-28
| | | | | | | | | | | | | | | | | | | | for general readability. Major changes: - Remove the intermediate Attribute -> LabelAndConfiguration multimap (computed in resolveAttributes). Instead, feed discovered values directly into the final Attribute -> Dependency map via a new RuleResolver interface. - Remove all references to LabelAndConfiguration. The configuration is always the owning rule's configuration except for two special cases: late-bound attributes with splits and late-bound attributes with LateBoundDefault.useHostConfiguration. The original interface made this very unclear and required a lot of awkward and sometimes incorrect logic. The new interface only involves configurations for the cases that actually need them. - Remove an ugly hack caused by BuildConfiguration.evaluateTransition mixing poorly with LateBoundDefault.useHostConfiguration (https://github.com/bazelbuild/bazel/blo[]e172693c27f3efc95ed163e43a9f0a7a6fb4017/src/main/java/com/google/devtools/build/lib/analysis/DependencyResolver.java#L488). - Remove a hack that applies split transitions twice because of BuildConfiguration.evaluateTransition mixing poorly with late-bound split attributes (https://github.com/bazelbuild/bazel/blo[]e172693c27f3efc95ed163e43a9f0a7a6fb4017/src/main/java/com/google/devtools/build/lib/analysis/DependencyResolver.java#L319). This happens to be innocent now but won't be when nested splits are possible. - Solidifies the API contract for Attribute.LateBoundDefault.useHostConfiguration. - Applies clearer naming and more consistent ordering to method parameters. - Better documentation. This is all also prep work for dynamic split transitions. tl;dr: late-bound attributes are legitimately special. Treat them that way to make the rest of DependencyResolver cleaner and hack-free. -- MOS_MIGRATED_REVID=128582618
* Remove outdated commentGravatar Michajlo Matijkiw2016-07-27
| | | | | -- MOS_MIGRATED_REVID=128510907
* Adjust visibility of ComputedDefault dependenciesGravatar Mark Schaller2016-07-27
| | | | | | | Also clarify that the returned list is immutable. -- MOS_MIGRATED_REVID=128482720
* Prohibit duplicate addition of aspect to an attribute and improve diagnostics.Gravatar Dmitry Lomov2016-07-19
| | | | | -- MOS_MIGRATED_REVID=127808009
* Add allow_single_file in attr.label, deprecate single_file.Gravatar Laurent Le Brun2016-07-05
| | | | | -- MOS_MIGRATED_REVID=126620866
* Reorganize Skylark Reference documentation.Gravatar Dmitry Lomov2016-06-29
| | | | | -- MOS_MIGRATED_REVID=126081020
* Refactoring: Introduced AttributeValueSource to handle attribute name ↵Gravatar Florian Weikert2016-05-12
| | | | | | | | | | | | validation and conversion for different types of attributes. Two reasons for this change: 1. These tasks shouldn't be the business of SkylarkRuleClassFunctions which previously handled such things. 2. With unknown commit we have to take care of three different types of attributes (normal vs. late-bound vs. computed default), which means that a boolean argument is no longer sufficient. -- MOS_MIGRATED_REVID=122136679
* 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
* Add attribute validation of mandatory native providersGravatar Liam Miller-Cushon2016-05-03
| | | | | | | and use it to validate that :java_toolchain has a JavaToolchainProvider. -- MOS_MIGRATED_REVID=121396726
* 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
* Introduce SplitTransitionProvider, to determine the split transition on an ↵Gravatar Chris Parsons2016-04-20
| | | | | | | attribute based on the Rule itself (the transition may thus be determined based on the values of other attributes of the rule) -- MOS_MIGRATED_REVID=120275649
* Rename LateBoundLabel#getDefault(Rule, AttributeMap, T) to #resolve().Gravatar Lukacs Berki2016-04-19
| | | | | | | Its old name was confusing because resolve() and getDefault() do radically different things: getDefault() returns a good enough lie for when BuildConfiguration is not available, and resolve() resolves the dependency when we do have a BuildConfiguration. -- MOS_MIGRATED_REVID=120212630
* Remove SkylarkAspectClass.getDefintion.Gravatar Dmitry Lomov2016-04-07
| | | | | -- MOS_MIGRATED_REVID=119162307
* Remove AspectClass.getDefinitionGravatar Dmitry Lomov2016-04-07
| | | | | | | | | | Aspect becomes a triple (AspectClass, AspectDefinition, AspectParameters) and loses its equals() method. After this CL, SkylarkAspectClass.getDefintion still exists and is deprecated. -- MOS_MIGRATED_REVID=119159653
* Make the Attribute.Builder.cloneBuilder() also copy aspects.Gravatar Carmi Grushko2016-03-31
| | | | | -- MOS_MIGRATED_REVID=118699141
* fix typo: "is produce" -> "is produced"Gravatar Cal Peyser2016-03-15
| | | | | -- MOS_MIGRATED_REVID=117202268
* Improve error when allowedFileTypesForLabels is not setGravatar Liam Miller-Cushon2016-03-11
| | | | | -- MOS_MIGRATED_REVID=116980421
* Python provider is now available in SkylarkGravatar Yun Peng2016-03-03
| | | | | | | | | | | | | Using mandatoryProvidersList to validate python rules' dependency. Added a SkylarkProvider named 'py' which is a SkylarkClassObject in Java and a struct in Skylark. Native python rule and Skylark python rule should have this provider so that they can depend on each other. RELNOTES[NEW]: Native python rule can depend on skylark rule as long as skylark rule provides 'py' provider. -- MOS_MIGRATED_REVID=116241504
* Changed mandatoryProviders to mandatoryProvidersListGravatar Yun Peng2016-02-22
| | | | | | | | "mandatoryProvidersList" is a list of sets of providers. For any rule, if it provides all the providers from one of those sets, we consider the dependency valid. -- MOS_MIGRATED_REVID=115221394
* Implement TODO from: ↵Gravatar Greg Estren2016-02-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://github.com/bazelbuild/bazel/blo[]fbbd6a32b95ba746f09dae1eaeaccf675cd5b3/src/main/java/com/google/devtools/build/lib/packages/Attribute.java#L1045 This allows the default value computation for latebound attributes to consider the values of configurable attributes. This is most directly useful for user-definable Skylark defaults, which have full access to the values of all non-latebound attributes. Without this change, this kind of scenario crashes Bazel. For example: ------------------ select_rules.bzl: ------------------ def _impl(ctx): ctx.file_action( output=ctx.outputs.out_file, content=ctx.attr.string_value, ) return struct() # Bug does not manifest without using this as a default. def _derived_value(attrs, _): return Label("//some:dep") selector_rule = rule( implementation=_impl, attrs={ "string_value": attr.string(default=""), "out_file": attr.output(), "_derived": attr.label(default=_derived_value), }, output_to_genfiles=True, ) def selector_macro(name, out_file="", string_value=""): # This will fail with selectors. selector_rule( name="%s_skylark" % name, string_value=string_value, out_file=out_file + ".skylark", ) # This does not. native.genrule( name="%s_genrule" % name, cmd="echo '" + string_value + "' > $@", outs=[out_file + ".genrule"], ) native.filegroup( name=name, srcs=[":%s_genrule" % name, "%s_skylark" % name], ) ------------------ BUILD.bzl: ------------------ config_setting( name = "selector", values = {"compilation_mode": "opt"}, ) selector_macro( name = "this_rule", string_value = """soup? """ + select({ ":selector": "no, thank you.", "//conditions:default": "yes, please!!", }), out_file = "this_rule.txt", ) -- MOS_MIGRATED_REVID=114326474
* Move annotation classes used for referencing framework Java classes from ↵Gravatar John Field2015-12-16
| | | | | | | | | | | | | | Skylark into their own package. This allows, e.g., classes in the syntax package to access classes in the cmdline package without creating circular dependencies. While we're here: - Removed a couple of unused BUILD deps flagged in []. - Updated SkylarkRuleImplementationFunctionsTest to remove non-ASCII characters and clarify the intent of the test. -- MOS_MIGRATED_REVID=110360763
* 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
* Implement Skylark aspects originating from Skylark rules.Gravatar Dmitry Lomov2015-11-26
| | | | | -- MOS_MIGRATED_REVID=108777120
* Workaround javac 1.7 bugGravatar Dmitry Lomov2015-11-19
| | | | | -- MOS_MIGRATED_REVID=108243881
* --Gravatar Carmi Grushko2015-11-12
| | | | MOS_MIGRATED_REVID=107604619
* 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
* Provide a way to explicitly constraint-enforceGravatar Greg Estren2015-10-29
| | | | | | | | | | | attributes that would otherwise be skipped by default policy. This is the simplistic start to a user-controllable enforcement policy API. -- MOS_MIGRATED_REVID=106530210
* 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
* 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
* Change Attribute.skipConstraintsCheck() (and similar methods)Gravatar Greg Estren2015-09-25
| | | | | | | | | | | | | to Attribute.skipPrereqValidatorCheck. This is to disambiguate the concept of "constraints" and keep the word consciously focused on Bazel's *new* constraint system. The changed methods refer to checks done by PrerequisiteValidator, which is basically an adhoc version of the "old" system (e.g. checking visibility) -- MOS_MIGRATED_REVID=103872412
* 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
* Prevented catching/wrapping of InterruptedExceptions, especially in ↵Gravatar Florian Weikert2015-09-14
| | | | | | | BaseFunction. -- MOS_MIGRATED_REVID=102988766
* Avoid checking visibility and other constraints for the lipo dependency.Gravatar Ulf Adams2015-09-08
| | | | | | | | | The lipo dependency is artificial; it's an artifact of how LIPO is implemented in Bazel. Running these checks doesn't make sense; they unnecessarily disallow perfectly valid scenarios. -- MOS_MIGRATED_REVID=102550286
* Aspects can get information from their base rule.Gravatar Marian Lobur2015-09-02
| | | | | -- MOS_MIGRATED_REVID=102126786
* Implement the core structure for dynamic configurations.Gravatar Greg Estren2015-08-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a big change, so let me walk you through the key pieces: 1) This cl provides an alternative mechanism for creating configurations and doing configuration transitions that's "dynamic" in that the configurations can be created on the fly and the transitions are arbitrary mappings from BuildOptions --> BuildOptions that can also be created on the fly. It also integrates this with ConfiguredTargetFunction, so the configured target graph automatically uses this framework. 2) It does *not* replace old-style (which we'll call "static") configurations. For a number of important reasons: It's not yet at feature parity (particularly: no LIPO). It's not remotely tested across real projects enough to have confidence that it's battle-ready. It doesn't yet handle certain "special" functions like BuildConfiguration.prepareToBuild() and BuildConfiguration.getRoots(). It still relies on the old static transition logic to determine what transitions to apply (eventually we'll distribute that logic out, but that's too much for a single cl). We need the option to toggle it on and off until we have enough confidence in it. So with this cl, builds can be done in either mode. 3) The new flag --experimental_dynamic_configs toggles use of dynamic configurations. 4) Dynamic configurations are created with the Skyframe function BuildConfigurationFunction (this was already created in an earlier change). This consumes a BuildOptions and a set of configuration fragments to produce a BuildConfiguration. 5) Dynamic transitions are instances of the new class PatchTransition, which simply maps an input BuildOptions to an output BuildOptions. 6) Since static and dynamic configurations have to co-exist (for now), this cl tries hard to keep today's transition logic defined in a single place (vs. forking a dedicated copy for each configuration style). This is done via the new interface BuildConfiguration.TransitionApplier. BuildConfiguration.evaluateTransition is modified to feed its transition logic into TransitionApplier's common API. Both dynamic and static configurations have their own implementations that "do the right thing" with the results. 7) The transition applier for dynamic configurations basically stores the Transition, then allows DependencyResolver (which calls BuildConfiguration.evaluateTransition) to return Dependency instances containing that Transition (vs. a BuildConfiguration, which they traditionally contain). 7.5) An earlier variation of the dynamic transition applier retained BuildOptions (e.g. when it got a Transition it immediately applied it to get its output BuildOptions, then stored that). This had the advantage of making composing of transitions easier, especially within BuildConfiguration.evaluateTransition (which can theoretically apply multiple transitions to the input configuration). But it turns out that applying transitions has a cost, and it's simply more performant to pass them through until they're really needed. 8) In dynamic configuration mode, after ConfiguredTargetFunction gets its deps (e.g. an <Attribute, Dependency> multimap), it "trims" the configurations for its dependencies by a) only including config fragments required by the deps' subtrees and b) applying the transitions that came from 7). This all happens in the new method ConfiguredTargetFunction.trimConfigurations. 9) trimConfigurations is heavily performance-optimized based on a lot of experience running this through a large project within Google. As it turns out, the cost of host transitions can be atrocious (because there are a lot of them). Also, BuildOptions.clone() is expensive. And just creating BuildConfiguration SkyKeys also has a cost (largely because of BuildOptions cloning), so that shouldn't be done except when really necessary. My experience with this convinced me it's worth making this method complicated for the sake of making it fast. Since it basically visits every edge in the configured target graph (at least), it really needs to be slick. 10) Since host transitions in particular are problematic w.r.t. speed, I compute the host *once* in ConfigurationCollectionFunction.getHostConfiguration() and expose that reference to ConfiguredTargetFunction and other Skyframe functions. This limits recomputation to just when the fragments are trimmed. 11) Since options cloning is expensive, I'm doing something scary: exposing a BuildConfiguration.getOptions() method that returns a direct reference. Since BuildOptions is mutable, this is dangerous in the wrong hands. I can experiment with going back to cloning (with the caching of host transitions it may not matter as much), but we may ultimately have to put up with this risk for the sake of performant analysis time. What would be *really* awesome would be to make BuildOptions immutable. But that's not going to happen in this cl. So in short, the key abstractions in this cl are: - PatchTransition - BuildConfiguration.TransitionApplier - ConfiguredTargetFunction.trimConfigurations The current implementation imposes no analysis time penalty -- MOS_MIGRATED_REVID=101474620
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 10:46:03 +0000