| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
In preparation for linking the parsed and unparsed values of options, consolidate and standardize our representation of the flag values as we received them (what is meant by "unparsed" values in this case). This was being done separately in ParseOptionResult, which, with extra context added, is being folded into UnparsedOptionValueDescription. We now track how an option was provided and where it came from for all option parsing.
RELNOTES: None.
PiperOrigin-RevId: 168682082
|
| |
|
|
|
|
|
|
|
|
| |
option lists.
Tracking the names together for option identification was useful, but then the same list was being used as the source of options for the parser, which lead to some options being listed twice.
Also complete a few tests that should have already been tested in different orders.
PiperOrigin-RevId: 168024719
|
| |
|
|
|
|
| |
Check that the option has a non-empty name and that it does not use deprecated categories. While we're at it, check that the names for options that are flags (all but INTERNAL flags, which are not meant to be used on the command line) are sensible.
PiperOrigin-RevId: 167182172
|
| |
|
|
|
|
|
|
|
|
| |
extractions of OptionDefinitions.
We already had caching of OptionsData objects, for a list of OptionsBases, but repeated the reflective work for the same OptionsBase if it appeared in different lists. Now that the @Option-annotation specific state is isolated to the OptionDefinition object, this can be trivially cached by OptionsBase.
There are a few additional convenient side effects to this change. This should slightly decrease the memory use of the OptionsParser, since it already cached this map per options-base, and now only requires a single copy. It also means that parts of the code base that needed details of an option's definition no longer need to either obtain an option definition themselves or need access to an OptionsData object, which should be private to the OptionsParser anyway.
PiperOrigin-RevId: 167158902
|
| |
|
|
|
|
|
|
|
|
|
| |
The information about whether a converter correctly matches the type of option it is meant to convert strings to is available at compile time. There is no reason to do this check at runtime.
Now, for an option to compile, it will need to have a converter that matches the option's type, taking into account whether the option is expected to accumulate multiple values. If it does not specify its own converter, a matching converter in the Converters.DEFAULT_CONVERTER list must be found, and the default value provided must be parseable by the matching default converter.
Remove tests that were testing failure modes which no longer compile.
RELNOTES: None.
PiperOrigin-RevId: 167092773
|
| |
|
|
|
|
|
|
|
|
|
| |
Removes some duplicate computation by memoizing the results. Consolidates caching into a single optionDefinition object, instead of having multiple caches that go from the option name to different parts of what defines an option.
Fly-by cleanup of OptionDescription's contents, all contents that are statically defined as part of an option are in OptionDefintion, while expansion data, which depends on the existence of other options, is more clearly stored separately.
Will move the converter-to-option type matching sanity checks to a compile time check in a later change.
RELNOTES: None.
PiperOrigin-RevId: 166912716
|
| |
|
|
|
|
|
| |
The rationality checks failed as RuntimeExceptions that weren't getting reported properly because the options parser is created too early in Bazel's lifetime to be reported properly to standard error. This was a minor annoyance for authors of new options, and there was nothing gained by waiting until runtime to check these values.
RELNOTES: None
PiperOrigin-RevId: 166395759
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This requires us to have OptionsData for all usage messages, since static functionality is being removed, but this should already have been the case. It was added as an optional argument when the expansion function feature was added, but there is actually no reason not to require it, as the public interface for usage text was already computing the optionsData anyway.
PiperOrigin-RevId: 165386893
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
The type was ignored, and it was expected that all expansion flags had
no value of their own, but was not checked.
PiperOrigin-RevId: 158261788
|
| |
|
|
|
|
|
|
| |
The no_ prefix was initially undocumented, but its support has over time
lead to a number of inconsistencies.
RELNOTES: --no_ prefix no longer recognized.
PiperOrigin-RevId: 157631435
|
| |
|
|
|
|
|
| |
You can now use the annotation @UsesOnlyCoreTypes on a subclass of OptionsBase, to indicate that all of its options' types are restricted to a whitelist of immutable and serializable types. Subclasses of the annotated class must also follow the same restriction.
RELNOTES: None
PiperOrigin-RevId: 154328920
|
| |
|
|
| |
PiperOrigin-RevId: 153610163
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This lets us easily get all options classes of a parser, or all fields of those options classes, in a deterministic way.
RELNOTES: None
PiperOrigin-RevId: 153376699
|
| |
|
|
|
| |
--no_ prefixes for boolean flags are deprecated. Error out nicely if --no_ is supplied.
PiperOrigin-RevId: 152434290
|
| |
|
|
|
|
|
|
|
|
|
|
| |
--incompatible_* flags
Note that if a developer adds a poorly-formatted incompatible change @Option, constructing an OptionsParser will now fail with an unchecked exception. This can cause some unit tests to fail in unexpected ways, but the developer should see an appropriate error message when the server starts up.
To be added: A separate integration test that ensures the expansions of --all_incompatible_changes don't clobber each other.
RELNOTES: None
PiperOrigin-RevId: 151858287
|
| |
|
|
|
|
|
|
|
| |
Prevent OptionsBases with conflicting names due to --no boolean flag aliases to
successfully combine into parser.
Also remove the comment about --no_ not being documented, since it has been documented since Bazel was open-sourced.
PiperOrigin-RevId: 151738453
|
|
|
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
|
ccalvarin
brandjon