| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
OptionsParserTest are implemented in ParamsFilePreProcessorTest, ShellQuotedParamsFilePreProcessorTest and UnquotedParamsFilePreProcessorTest.
RELNOTES: None.
PiperOrigin-RevId: 174359569
|
|
|
|
|
|
|
| |
Make sure that multiple calls to parse() follow each other sequentially. This is necessary for blazerc expansion, which occurs first in command order, then blazerc order.
RELNOTES: None.
PiperOrigin-RevId: 174343241
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instances.
Stop storing the canonical list of arguments separately. For the canonicalize-flags command, we want to avoid showing options that either have no values in their own right (such as expansion options and wrapper options) and instances of options that did not make it to the final value. This is work we already do in OptionValueDescription, so we can generate the canonical form from the values tracked there, instead of tracking it separately.
This means the canonical list is more correct where implicit requirements are concerned: implicit requirements are not listed in the canonical form, but now the values they overwrote will be correctly absent as well.
Use this improved list for the effective command line published to the BEP.
RELNOTES: Published command lines should have improved lists of effective options.
PiperOrigin-RevId: 173873154
|
|
|
|
|
|
|
| |
Add warnings for behavior that is likely unexpected. Expansion values do not accept values at all, and implicit requirements are set regardless of whether the option was turned "on" or not, so warn in the cases where this weird behavior might rear its ugly head.
RELNOTES: None
PiperOrigin-RevId: 172883214
|
|
|
|
|
|
|
|
|
| |
It was added as a potential fix for --config (an expansion flag with values), but this would have required forcing the parser to know the config's expansions at parsing time, which is not currently possible. Instead, we will use the new addition of option-location tracking to make sure we expand options at a the correct place, even if the expansion is triggered after the fact.
This is mostly a straight forward undoing of https://github.com/bazelbuild/bazel/commit/7c7255ec8d6da20526c2c4078c57aadaf3dd3612, except where the context has changed. Notably, implicit requirements are effectively treated like expansion flags, so special casing in OptionDescription could be removed.
RELNOTES: None.
PiperOrigin-RevId: 172514997
|
|
|
|
|
|
|
| |
ShellQuotedParamsFilePreProcessor. This covers all of the tools packaged in the ResourceProcessorBusyBox.
RELNOTES: None.
PiperOrigin-RevId: 172485486
|
|
|
|
|
|
|
|
|
| |
An option has precedence over previous options at the same enum-valued priority. Track its placement in this ordering explicitly.
This will allow after-the-fact expansion of expansion options such that they correctly take precedence or not compared to other mentions of the same flag. This is needed to fix --config's expansion.
RELNOTES: None.
PiperOrigin-RevId: 172367996
|
|
|
|
|
|
|
| |
Remove an unnecessary warning and make all warnings for option conflicts print only if the option values are not equal.
RELNOTES: None.
PiperOrigin-RevId: 172124261
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
OptionDescription is basically a hack to get the expansion data for options from outside the options parser, but it was being used at various points of invocation policy enforcement. In order to correctly track option origin, we only want to get this information once. Do it during the invocation policy expansion stage, not at enforcement, so that we track the information of the option's origin in the original invocation policy passed to the enforcer, not the expanded one.
PiperOrigin-RevId: 171661669
|
|
|
|
|
|
|
|
|
| |
This is part of the effort outlined in https://bazel.build/designs/2017/07/13/improved-command-line-reporting.html. The refactoring of the options parser is not yet complete, so we still do not have complete & correct information about the canonical command line. Where the information is blatantly incorrect, a best approximation was made, with comments and tests documenting the deficiencies.
Change the names of the initial CommandLine fields in the BEP to be explicitly identified as unstructured.
RELNOTES: None.
PiperOrigin-RevId: 171625377
|
|
|
|
| |
PiperOrigin-RevId: 171017483
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If setting flag --use_new_category_enum, group the options by the new categories in both the command line output and the "everything-as-html" output used for the generated docs at https://bazel.build/versions/master/docs/command-line-reference.html. In the html output, the effect and metadata tags are listed for each option, with links to their descriptions at the bottom of the page. The tags only appear in the terminal output in -l/--long/--help_verbosity=long, and only the names appear.
This is still experimental as the majority of options do not yet use the new categorization system. The new output can be seen in command-line-reference.html format by adding the new flag to the "help everything-as-html" line in //src/main/java/com/google/devtools/build/lib:gen_command-line-reference.
The html output is in the same order as before (by blaze rule, with inherited options not repeated), which means it still has duplicate options, that should ideally be fixed separately. I propose either dropping the high-level grouping and just grouping the options by documentation category, or potentially grouping them by optionsbase in some non-class-naming way, and listing the commands that they apply to, as more and more optionsbases are used by multiple commands without being inherited (for example, all BuildEventServiceOptions are listed 20 times). People probably use ctrl-f to navigate this page anyway. Once we know that we only list each option once, we can actually have links to the options, which will make it possible to have links in the expansion lists.
Issue #3758
RELNOTES: added experimental --use_new_category_enum to the help command to output options grouped by the new type of category.
PiperOrigin-RevId: 170116553
|
|
|
|
|
|
|
| |
Ideally, the canonical form we output from OptionUtils would be the same as for the command canonicalize-flags, but that must wait for dependencies to be cleaned up. Still, in the meantime, keep the --foo=1 normalization of --foo, and apply it to all other boolean flag values (t,true,yes,y, and false equivalents), so that the canoncalize-flags output is more canonical, even if it isn't using the --[no]foo form yet.
RELNOTES: Boolean flag values will now get normalized to 1 or 0 in canonicalize-flags output.
PiperOrigin-RevId: 170084599
|
|
|
|
|
|
|
|
|
| |
A single instance of an option has a single origin, but the final value only has a single origin if it has a single value. For multi-valued options, it is wrong to expect that the final value of an option will have a single parent. Track the option parents (which option expanded to the current instance, if any) in the right place, with the ParsedOptionDescription.
Also fix some inconsistent spelling of 'dependent,' in favor of the American English standard.
RELNOTES: None.
PiperOrigin-RevId: 169487515
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Options that expand to other options are expansion options and the options they expand to have values that were expansions. This can be a bit confusing. Removes the isExpansion() call that is somewhat ambiguous, and forces option users to explicitly check the option definition for this information.
Also provide a parallel boolean function for implicit requirements, so that we stop querying for the length of the implicit requirement all over the place.
RELNOTES: None.
PiperOrigin-RevId: 169461566
|
|
|
|
|
|
|
| |
formats specified in ParameterFile.ParameterFileType. Also maintain the currently used parsing style of whitespace split arguments that allows single and double quoting and whitespace and quote escaping. This style of parsing is for a format not currently generated and will be removed once all consuming actions have been converted to using a supported format explicitly.
RELNOTES: None.
PiperOrigin-RevId: 169437362
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add recursive test_suite rules for all tests that
ci.bazel.io runs for Windows, and set the
top-level test_suite as the CI test target.
Doing so shortens the command line and works
around https://github.com/bazelbuild/bazel/issues/3742
I verified that the old set of tests are the same
as the new set.
Change-Id: Id8d5da3f0c03c9b8969a9f8e1e9a3096888365aa
PiperOrigin-RevId: 169242858
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a vexingly large world of possible option types, each with its own quirks of how it interfaces with new inputs as they come in: values can be
- overridden (default)
- concatenated (allowMultiple)
- flattened (allowMultiple that accepts list inputs)
- disappear into additional flag inputs (expansion flags)
Or some combination of the above, in the case of flags with implicit dependencies and wrapper options.
Begin removing the error-prone treatment of all option types with conditional branches. This model of the different options will make it much easier to isolate the option-type specific logic with the command-line parsing logic. Flags that affect other flags (implicit requirements, expansions, and wrappers) will be migrated in a later change.
This CL does not change flag parsing semantics, just migrates the current parsing logic to the new class structure.
RELNOTES: None.
PiperOrigin-RevId: 169239182
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We get UnparsedValues after ... parsing the options. So that doesn't
make sense. What was meant was that it wasn't converted to the final
value.
In an effort to make this distinction more clear, this change will
make the terminology more consistent. The `--foo=bar` step is
"parsing" and the `bar -> Object` step is "converting" (it is, in
fact, done by Converters).
RELNOTES: None.
PiperOrigin-RevId: 168852847
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
These classes are mostly used during the options parsing process itself, and are barely a part of the options parser interface, so they really don't belong in OptionsParser.java. They are also about to change significantly, so taking this opportunity to split them out.
RELNOTES: None.
PiperOrigin-RevId: 168400162
|
|
|
|
|
|
|
| |
Now that we have a standard way of referring to an option, remove all of the places that we were referring to them by their name. Since options can have multiple names, this is more clear and provides the additional information needed to understand the option. It also stops the habit of requesting unqualified strings, which was hard to read.
RELNOTES: None.
PiperOrigin-RevId: 168254584
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
How expanding flags interact with other possible flag qualities is not defined. Should repeated values have effects multiple times and accumulate? This doesn't really make sense, expansion flags don't have values that would accumulate. For this reason, don't allow expansion options to have allowMultiple set to true.
Likewise for other behaviors.
PiperOrigin-RevId: 167580641
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/0071b396776be4d146fd271499716dd5dea6f7e9: Enable parameter files for manifest merger actions.
NEW: Using shell quoted param files and unescape arguments in ParamsFilePreProcessor to avoid miss-processing --manifestValues arguments containing whitespace.
RELNOTES: None.
PiperOrigin-RevId: 166858411
|
|
|
|
|
|
|
|
|
| |
Blaze options.
This change is in preparation for unknown commit which also needs to iterate over all options, but has to execute a different action than getOptionsCompletion().
As a result, applying the visitor patterns helps to avoid duplicate iteration code.
PiperOrigin-RevId: 166515117
|
|
|
|
|
|
|
|
| |
non-final and non-static.
Remove the now redundant check in the testing framework, as the cases being tested no longer compile. Keep tests that check the contents of the OptionsBase as a whole, however, as this is still not being tested at compile time.
PiperOrigin-RevId: 166239209
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Like the terminal output, there was some discrepancy between the expansion function and static expansion behavior. Also adds html usage output tests.
PiperOrigin-RevId: 165584454
|
|
|
|
|
|
|
| |
Add unit tests for individual flag usage output. Also move around some of the sample expansion function test options, which could be used more widely, to minimize recreating the boilerplate samples.
RELNOTES: None.
PiperOrigin-RevId: 165478776
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Fix bug where a null value in the expansion text lead to a NullPointerException.
RELNOTES: None.
PiperOrigin-RevId: 164061496
|
|
|
|
|
|
|
| |
Also change it to java.time.Duration, rather than Jodatime. Now that we're on
Java 8, we no longer need Jodatime.
PiperOrigin-RevId: 162917526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because OptionsBase implements equals() as a final method, subclasses can
only add fields in certain ways for OptionsBase to properly obey equals()
semantics. Specifically, all fields must be public and @Option annotated.
The OptionsTester checks for these two things.
Additionally, Converters must make sure to always return equals() values
on equals() (or equivalent) input. The OptionsTester includes a check that
all Converters named by the OptionsBase subclass being tested have matching
ConverterTesters, and if valid default values are specified (i.e., on
Options which are not multi-valued or default null), that these defaults
are among the values tested by the ConverterTesters.
The ConverterTesters themselves are wrapped EqualsTesters, testing that
the output of a Converter obeys equals() as expected for the same input
(or equivalent ones), and is consistent across calls to the same Converter
instance or different Converter instances.
Between these two, OptionsBase subclasses can have reasonable certainty
that two instances of themselves which were parsed equally - or underwent
equivalent transformations - will be equal.
This does not actually test any OptionsBase subclasses or Converter
implementations; it merely adds a framework. Future changes will cover
automatically testing all of the OptionsBase subclasses in a
RuleClassProvider, but naturally, this requires writing test data for
each Converter in the Bazel codebase first.
RELNOTES: None.
PiperOrigin-RevId: 162522445
|
|
|
|
|
|
| |
//src/main/java/com/google/devtools/common/options:options is now free of bazel protos, once again.
PiperOrigin-RevId: 162385612
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
In order to break out the proto dependency of the OptionsParser, add a java-only enum that users of the options parser can depend on, instead of requiring the dependency on the protobuf. The protocol buffer definition is kept in order to be used for command line reporting in the BEP, so a test is added to make sure that the two are kept in sync.
Also add some clearer guidance for how to go about selecting, and adding, option categories and tags.
Migrating the current uses of the proto enum to this one will happen in a follow-up change.
PiperOrigin-RevId: 161971077
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
testing.
Unlike in the production flags, these flags are only used for internal testing. Tagged them as NO_OP instead of the default UNKNOWN to make it clear that we do not need these to become properly tagged.
PiperOrigin-RevId: 160526472
|
|
|
|
|
|
|
| |
This lets us change what it expands based on the argument passed to the flag.
RELNOTES: Allows flags that expand to take values.
PiperOrigin-RevId: 160298412
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was originally included in runtime due to external dependencies, and
a desire to keep the options parser a general options library. These
dependencies have been or will be removed, and there are plenty of other
general flag libraries.
InvocationPolicy is fundamentally acting on the properties of this
specific OptionsParser and needs proper access to it for the proper
solution to a number of existing bugs, which means having access to
things that should be package private.
PiperOrigin-RevId: 158523111
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 158279811
|
|
|
|
|
|
|
| |
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
|