summaryrefslogtreecommitdiff
path: root/java/com/google/devtools/common/options/Option.java
AgeCommit message (Collapse)Author
2018-05-04Remove wrapper options support.ccalvarin
RELNOTES: None. PiperOrigin-RevId: 179588174 GitOrigin-RevId: 16f1c19c2c4f68555bb23891e3a4da4d5ac4a68d Change-Id: I089b4b2e4c846682db552aa4c0e0905142e9278b
2017-10-24Expand implicitRequirements in the location of the option that required it.ccalvarin
Removes the special casing of implicit requirements. Accumulating them and parsing them at the end of the parse() function was never enough to actually guarantee that the value not be replaced. I've gone through all options with implicit requirements to make sure that the expectation is checked after options parsing, so this change should be relatively safe. Implicit requirements is still a broken concept - they don't actually expand based on the value given, so a user that is explicitly NOT setting a flag might unwittingly be setting all the requirements for that unset flag. Removing it fully requires redesigning or removing the flags that set it, though, so for now we are standardizing the behavior so that it behaves like any other expansion options, just one with a value. Also consolidate the deprecated wrapper option behavior into the expansion work. It will soon be removed entirely, but for now it can get grouped in with the expansion logic, so that its differences are more explicit. RELNOTES: None. PiperOrigin-RevId: 171957502 GitOrigin-RevId: faf2db22277bd0b074a0a8c5cd4533a735eff31a Change-Id: I84a1461624207d3d43786ebc69d17ab6f16f9ec8
2017-09-22Deprecate wrapperOptions.ccalvarin
In order to discourage new uses (there shouldn't be any, but just in case), make it illegal to set wrapperOption=true for non deprecated options. RELNOTES: None. PiperOrigin-RevId: 169477990 GitOrigin-RevId: 125e88d693f04df7f9039906dc7bb03245fb61f7 Change-Id: Iab3e66245c1cfb53aada05654cc304a4334ddd9a
2017-09-06Update comments about the option processor.ccalvarin
There were a few places where the current state of the world was not clear. RELNOTES: None. PiperOrigin-RevId: 167273651 GitOrigin-RevId: a8c00e2f40ab8a57e3630e774e8d0d9354f38472 Change-Id: Ic7293724cf4789bef63284604f1a3eb2c2f61b86
2017-08-25Add OptionDefinition layer between the @Option annotation and its fields and ↵ccalvarin
the options parser. Removes any direct reads of the annotation outside of OptionDefinition. This allows for fewer manual checks for the annotation's existence, unifies error wording, and paves the way for potentially generifying the OptionsParser to accept different @Option-equivalent annotations. Also allows for cleanup of duplicate code by giving @Option-specific operations a clear home, such as sorts and default logic. In followup changes, we can eliminate some unnecessarily complex caching by instead memoizing values in the OptionDefinition. This will have the positive side effect of making sure reads come from the cached values. RELNOTES: None. PiperOrigin-RevId: 166019075 GitOrigin-RevId: e8aae03888a44ee8d5264c3d8f6b3adaeb830df5 Change-Id: Ie5ffe0c1983e89885a2bfcab8cf7565790f396fd
2017-07-20Make the @Option annotation depend on the java version of the tagging enums.ccalvarin
The option filters proto dependency can be removed from the OptionsParser. This is in response to option parser users that want to avoid the bazel-internal proto file in their dependencies. RELNOTES: None. PiperOrigin-RevId: 162249778 GitOrigin-RevId: c82a19714dac1210654640ac1f5ca4d96df716a8 Change-Id: If5368c1d0c8ec90d2f07489c742aef53e13ce046
2017-07-20Fold OptionUsageRestrictions into OptionDocumentationCategory and ↵ccalvarin
OptionMetadataTags. These are similar, no need to have both fields. Removing the "DOCUMENTED" default, the absence of UNDOCUMENTED will be used instead. Since requiring a documentation category for undocumented options doesn't make sense, list that as one of the OptionDocumentationCategories, but list HIDDEN and INTERNAL as part of OptionMetadata. These options should list UNDOCUMENTED as their category. PiperOrigin-RevId: 161515674 GitOrigin-RevId: 456adb2267343a4e2e64f082e77169c18f9e6060 Change-Id: Ia7dcbd5d38d4caa2d6d60f25b5a1f0c23735ca22
2017-07-20Enforce the new category and effect tags.ccalvarin
All options need to explicitly list their category and effect. If they are uncategorized, this makes the lack of information obvious. Remove defaults from the annotation to enforce this. Also enforce the sanity check that no option should have UNKNOWN or NO_OP effects listed with other effect tags. Includes some last default sets for options I missed in the previous mass-setting change, and some that were added since. PiperOrigin-RevId: 160641861 GitOrigin-RevId: 59a0e4f10bf037dcd4f257b2e21573fa1b690e93 Change-Id: Ia4d56acf71a4805df60d177e5525a9f7c180225b
2017-06-30Add option tagging and categorizing enums.ccalvarin
Begin work of transferring option categorization to a sustainable, documented setup. DocumentationCategories will replace the existing string category field, and will group flags in generated documentation. Each flag must belong to exactly 1 DocumentationCategory, whichever is most applicable or a new one. OptionEffectTags will document the effects of tags and will be used for filtering flags. These tags, unlike the categories, should be complete. All options that do affect Bazel's output should be tagged as affecting Bazel's output, for example. This is necessary for them to be useful when trying to isolate the cause of an issue or behavior by allowing irrelevant options to be filtered out. Each flag must have at least 1 intended behavior, so should have 1+ OptionEffectTag. If no effect tag applies, find a general tag that would apply and add it to all relevant options. OptionMetadataTags will hold information about the flag itself. Information about the lifecycle of a flag, for example, should belong in an OptionMetadataTag. It is useful for filtering, since it describes how trustworthy we might think the flag would be, but does not actually describe the “intent” or “meaning” of a flag. This can be an empty list, but options can also have multiple OptionMetadataTags All options will be switched from the old "category" field to this new system. A few general OptionsBases are provided as an example. PiperOrigin-RevId: 160180328 GitOrigin-RevId: e73f881b66e5540051f92f8ffab5570b6856fea8 Change-Id: I607f9bce70aa841e2f46510d2fac368a29e35453
2017-04-27Deprecate use of option category to describe documentation level / usage ↵ccalvarin
restrictions. Prevent the old category strings "undocumented," "hidden," or "internal" from being used as categories, to prevent developers from relying on deprecated behavior. PiperOrigin-RevId: 153525499 GitOrigin-RevId: 5d1042629e94e278dcc49db5f640829acc3bff1a Change-Id: I64cbb532e4bf98c98bd2bd7a6842af4737941d54
2017-04-18Remove the overloading of option category to cover documentation level.ccalvarin
This prevents having to parse the category, and allows the category to potentially be used in the future for information about all options, included undocumented, hidden, or internal options. Also rename DocumentationLevel to OptionUsageRestrictions, since INTERNAL was not really documentation related. PiperOrigin-RevId: 153367769 GitOrigin-RevId: 391d5d9d06f18d49baab037ebc10e4ec5efdb233 Change-Id: I1df7f73365fd70c40c81c179188ca6b04d2004d5
2017-03-22Add expansion functions to options parserJon Brandvein
This provides a way to programmatically define expansions of options based on what other options are defined for the parser. In particular, it will be used for the --incompatible_* changes mechanism, to turn on all incompatible change flags. Expansion functions are specified in the @Option annotation, similar to converters. They are computed when an OptionsParser is constructed, and inspect a preliminary version of its OptionsData to determine the expansion result. This is then cached in the final OptionsData used by the parser. Expansion information for usage strings is available, but only when the usage strings are obtained via the parser. -- PiperOrigin-RevId: 150817553 MOS_MIGRATED_REVID=150817553 GitOrigin-RevId: 22d261c21748fba31797f0de8bd98fb2ff2fd2f5 Change-Id: Iec0d628fbf873b2b3d7fb7f4c86ad809f9955dbb
2017-03-22Create "internal" category of command-line options.Michael Staib
This is intended to be used for "flags" which should never appear on the command line - things like configuration distinguishers, which are used internally and must be part of the build options, but should always be set to their default value at the top level. This is already a convention within Bazel, but doesn't actually work the way Bazel expects - flags with spaces can be set by simply escaping or quoting the spaces so that word splitting will not break on them. This means they can also be matched by config_settings, which pass a single string. Forbidding the parser from matching these flags solves both of these unintended cases. Existing cases like this have also been converted to internal. -- PiperOrigin-RevId: 150497246 MOS_MIGRATED_REVID=150497246 GitOrigin-RevId: a5aa916dc8c0e99c8fc91893246381f72b7066a9 Change-Id: I782990abd7e12010fe8b9ef35475b676e89011f8
2017-02-16Polish the command-line reference.Ulf Adams
- change options to print --foo=value - allow option to specify what "value" should be - update the documentation for the startup options - add some indentation to the descriptions - add some spacing between flag texts -- MOS_MIGRATED_REVID=125960618 GitOrigin-RevId: 6f09666d994b3bd7663eb3f95e2aeaf63c85b0d7 Change-Id: I228f26ed2cedf219ab1d32befde8ba765f33fc5a
2017-02-16Fix OptionsParserImpl.clearValue (and invocation policy by extension) to workAlex Humesky
correctly with flags that have expansion flags or implicit requirements. -- MOS_MIGRATED_REVID=121862297 GitOrigin-RevId: 92a3a811330d296c4801c43627c72b76900c8181 Change-Id: Ica77f4d454633d645e1eb42b1657c6bbd56505a6
2017-02-16Delete the defaultMultipleValue field from options and refactor the logic ↵Luis Fernando Pino Duque
for retrieving the default values of options. The field defaultMultipleValue was introduced in commit 51a491b89a9cd5f15c9a093a5693bc37e696e6e1 to allow defining a default value for options that set allowMultiple. However due to the limitations of the optionsParser end up being not useful since we cannot guarantee that an option that allows multiple has a converter that returns a list of values. Thus this CL deletes code that may confuse even more and clarifies the mechanism that the options currently use to obtain their default values. -- MOS_MIGRATED_REVID=120317261 GitOrigin-RevId: 31162bcf061cd58a5db628f51f3da5d7d43b7829 Change-Id: I31bd9714bb3950017453e24cc0ba37e5d7af94d1
2017-02-16Add a new field to options called defaultMultipleValue which enables setting ↵Luis Fernando Pino Duque
default values for flags whose allowMultiple is true. The behavior is the following: - If allowMultiple is false then behave as previously. - Otherwise for retrieving the default we now look at defaultMultipleValue instead of defaultValue and in the process it will apply the converter to each element. If no defaultMultipleValue is specified then the default value will be an empty list. -- MOS_MIGRATED_REVID=117558645 GitOrigin-RevId: 51a491b89a9cd5f15c9a093a5693bc37e696e6e1 Change-Id: I67b29e8ac94fb7ce5e6b72bfcf1383e2453cc29c
2017-02-16Adds an oldName attribute and a wrapperOption attribute to the @Option ↵Alex Humesky
annotation for the options parser. oldName indicates the old name for the option, and the option will be parsed under both name and oldName. wrapperOption indicates that the option is a wrapper for other options. For example, in "--foo=--bar=baz", --foo wraps --bar=baz. With wrapperOption set to true for --foo, the options parser will "unwrap" --bar=baz and parse them as top-level flags. -- MOS_MIGRATED_REVID=105924412 GitOrigin-RevId: 5f7e63e72a8843660e9e79d2afe994abee405bb1 Change-Id: I3b2b4bdf4b9306fb37d82e96536a0c28081fe75a
2017-02-16Adds a mechanism for invocation policy. The policy is taken through the ↵Alex Humesky
--invocation_policy startup flag and allows an application invoking Bazel to set or override flag values (whether from the command line or a bazelrc). -- MOS_MIGRATED_REVID=104160290 GitOrigin-RevId: 2f3f4cf925a760019fd089dd5ee771a3552fb278 Change-Id: Iaab02e38d4c221d2184112f2d9e079058604a5f9
2017-02-16Rationalize copyright headersDamien Martin-Guillerez
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 GitOrigin-RevId: f88f4d81acead9ef3e2f73d9a44afd76c2c239c1 Change-Id: I24bf6dcdbf1c77ea6ae5eaef65072ec9727d6fb7
2017-02-16Added an help command to dump all options for completionDamien Martin-Guillerez
`bazel help completion` dump all options completion pattern for each command, giving hints on the format of the completion residue (e.g., `label`, `path`, `{a,enum}`, ...). This dump can be used to generate completion scripts. -- MOS_MIGRATED_REVID=90743024 GitOrigin-RevId: 29728d4c37721aa88621a8578a7c2d7bfe8b5c68 Change-Id: Id4ce5e3f3efa0b8c4e70a77e5fa745d3e978efe5
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-14 07:14:28 +0000