aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/packages/SkylarkAspect.java
Commit message (Collapse)AuthorAge
* Migrate Aspect to skylarkbuildapiGravatar cparsons2018-05-15
| | | | | RELNOTES: None. PiperOrigin-RevId: 196726540
* Migrate annotations of SkylarkAttr to an interface class.Gravatar cparsons2018-04-30
| | | | | | | This isolates the API from the implementation. RELNOTES: None. PiperOrigin-RevId: 194850527
* Expose ObjcProtoAspect to Skylark.Gravatar cparsons2017-12-20
| | | | | RELNOTES: None. PiperOrigin-RevId: 179737025
* 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
* Remove deprecated legacy string representations of Skylark objectsGravatar vladmos2017-10-13
| | | | | | | | RELNOTES[INC]: The flag --incompatible_descriptive_string_representations is no longer available, old style string representations of objects are not supported anymore. PiperOrigin-RevId: 171952621
* Clean up string representations for aspectsGravatar vladmos2017-07-07
| | | | | | | | If --incompatible_descriptive_string_representations is passed, aspects are converted to strings using `str`, `repr` and `print` functions differently (more descriptive, without leaking information that shouldn't be accessible). PiperOrigin-RevId: 161116840
* Clean up string representations for functionsGravatar vladmos2017-07-07
| | | | | | | | | If --incompatible_descriptive_string_representations is passed, functions and rule classes are converted to strings using `str`, `repr` and `print` functions differently (more descriptive, without leaking information that shouldn't be accessible). PiperOrigin-RevId: 161087777
* Remove the ToolchainConstructor class and change uses to be either aGravatar John Cater2017-07-06
| | | | | | | | | Label or a ToolchainInfo provider. Part of #2219. Change-Id: Ia09070717f54eea10e1ab0303253714b58768548 PiperOrigin-RevId: 160995546
* Refactor PrinterGravatar vladmos2017-07-03
| | | | | | | It's now easier to customize Printer if in different situations objects should be printed differently. Also its API is cleaner now. Names of methods of SkylarkValue objects now reflect names of Skylark functions: SkylarkValue#repr and SkylarkPrintableValue#str. PiperOrigin-RevId: 160635154
* Automated conversion to Java 8Gravatar laurentlb2017-06-30
| | | | | | | With a few manual fixes for readability. RELNOTES: None. PiperOrigin-RevId: 160582556
* Add toolchains attribute to aspect.Gravatar John Cater2017-05-26
| | | | | | | Part of #2219. Change-Id: I39ced1f3e2605154771df9424d6ed2f971820baf PiperOrigin-RevId: 157002268
* Allow declared providers in attribute and aspect defintions.Gravatar Dmitry Lomov2017-03-06
| | | | | | -- PiperOrigin-RevId: 149169656 MOS_MIGRATED_REVID=149169656
* Allow Skylark aspects to advertise providers.Gravatar Dmitry Lomov2017-02-14
| | | | | | -- PiperOrigin-RevId: 147350507 MOS_MIGRATED_REVID=147350507
* 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
* 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 Skylark syntax to propagate an aspect to all attributes.Gravatar Dmitry Lomov2016-10-04
| | | | | -- MOS_MIGRATED_REVID=134793032
* Add 'provider()' function.Gravatar Dmitry Lomov2016-08-11
| | | | | -- MOS_MIGRATED_REVID=129889793
* Reorganize Skylark Reference documentation.Gravatar Dmitry Lomov2016-06-29
| | | | | -- MOS_MIGRATED_REVID=126081020
* Added more pointers to Aspect-related documentation.Gravatar Florian Weikert2016-06-21
| | | | | -- MOS_MIGRATED_REVID=125428066
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 06:57:34 +0000