aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/common/options/OptionsParser.java
Commit message (Collapse)AuthorAge
* Clean up code that directly imports nested classes like Builder, Entry, etc.Gravatar jcater2018-05-02
| | | | PiperOrigin-RevId: 195100670
* Remove alphabetical sorting of options in the canonical list.Gravatar ccalvarin2018-04-09
| | | | | | | This was broken for --config. Doing this properly requires keeping the order in which the options were given, which could be done either by filtering the ordered list according to which values affect the final outcome or by tracking the order correctly. I picked the later: the option order was not explicitly tracked for expansions before but now it is. RELNOTES: canonicalize-flags no longer reorders the flags PiperOrigin-RevId: 192132260
* Warn about config expansions as we do for other expansions.Gravatar ccalvarin2017-12-21
| | | | | | | | | If an expanded value overrides an explicit value, users who do not know the contents of the expansion may be surprised. We already warned about this for hard-coded expansions, and this is now applicable for --config expansions as well. This will only warn when a single-valued option has its value replaced. Options that accumulate multiple values in a list (e.g., --copt) will silently include both explicit and expanded values. RELNOTES: None. PiperOrigin-RevId: 179857526
* Change config expansion application order, gated by startup flag ↵Gravatar ccalvarin2017-11-20
| | | | | | | | | | | | | --expand_configs_in_place. --config options were expanded in a fix-point expansion, where in practice, the flags that --config values expanded to ended up between the normal bazelrc options and the command line's explicit options. Since the options parser has an order-based priority scheme and it accepts multiple mentions of a single-valued option, this conflicts with users' expectations of being able to override these config expansions by using the order in which they are mentioned. This change makes it possible to expand the config values defined in your bazelrc (or blazerc) files to occur in-place: --stuff --config=something --laterstuff will interpret the options that --config=something expands to as if they had been mentioned explicitly between --stuff and --laterstuff. In order to not break users relying on complex flag combinations to configure their builds, this behavior will not yet be turned on by default. Instead, use --expand_configs_in_place as a startup flag to test this feature. --announce_rc may be helpful for debugging any differences between the fixed point and in-place expansions. Once you've debugged your problems, add "startup --expand_configs_in_place" to your blazerc to stick to the new behavior. RELNOTES: Use --expand_configs_in_place as a startup argument to change the order in which --config expansions are interpreted. PiperOrigin-RevId: 176371289
* Compute canonical list of options using OptionValueDescription's tracking of ↵Gravatar ccalvarin2017-10-30
| | | | | | | | | | | | | 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
* Remove feature to allow expansion flags to have values.Gravatar ccalvarin2017-10-18
| | | | | | | | | 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
* Migrate all users of OptionsParser.enableParamsFileSupport to use the ↵Gravatar apell2017-10-18
| | | | | | | ShellQuotedParamsFilePreProcessor. This covers all of the tools packaged in the ResourceProcessorBusyBox. RELNOTES: None. PiperOrigin-RevId: 172485486
* Track Option placement within a priority category.Gravatar ccalvarin2017-10-18
| | | | | | | | | 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
* Clean up InvocationPolicy's use of OptionDescription.Gravatar ccalvarin2017-10-11
| | | | | | 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
* Add new option categorization and tagging information to HelpCommand's output.Gravatar ccalvarin2017-09-27
| | | | | | | | | | | | | 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
* Create multiple ParamsFilePreProcessors to allow parsing files using the ↵Gravatar apell2017-09-21
| | | | | | | 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
* Throw away the confusing UnparsedOptionValueDescription name.Gravatar ccalvarin2017-09-18
| | | | | | | | | | | | | | 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
* Pass the UnparsedOptionValues when setting or adding option values.Gravatar ccalvarin2017-09-14
| | | | | | | | Stop breaking the value apart to be recombined later. Also stop using OptionValueDescriptions as though we have a final option when expanding flags for invocation policy. These values are explicitly the output from parsing the expansion strings, not yet converted or combined with other values of the same flag. After this change, only UnparsedOptionValueDescription should be used when strings of flags are parsed, and OptionValueDescription should be used when the final version of a flag is created or used. PiperOrigin-RevId: 168688063
* Consolidate the "unparsed" option value tracking.Gravatar ccalvarin2017-09-14
| | | | | | | 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
* Move option value tracking classes to their own file.Gravatar ccalvarin2017-09-13
| | | | | | | 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
* Replace referrals to options by their name to option definitions.Gravatar ccalvarin2017-09-12
| | | | | | | 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 value tracking should refer to the option definitions, not just track ↵Gravatar ccalvarin2017-09-11
| | | | | | | | | | | option name. UnparsedOptionValueDescription and OptionValueDescription both had redundant information about options, since they tracked options by their names, and not their definition. Remove the redundancy. For getEffectiveOptions, the old behavior was relying on the fact that all options were given allowmulitple=false, which was wrong, so stop passing in the default value where it would get confused with values that have been created and tracked by the options parser. Instead, passing value=null is the way to indicate that an option is unset. RELNOTES: None. PiperOrigin-RevId: 168038067
* Options with oldNames will no longer get reported twice in the effective ↵Gravatar ccalvarin2017-09-11
| | | | | | | | | | 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
* Move caching of OptionDefinitions to be static, and remove uncached ↵Gravatar ccalvarin2017-09-01
| | | | | | | | | | 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
* Move default value & converter finding logic to the OptionDefinition class.Gravatar ccalvarin2017-08-30
| | | | | | | | | | | 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
* Refactoring: OptionsParser now uses the visitor pattern to iterate over ↵Gravatar fwe2017-08-28
| | | | | | | | | 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
* Add OptionDefinition layer between the @Option annotation and its fields and ↵Gravatar ccalvarin2017-08-22
| | | | | | | | | | | 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
* PolishingGravatar Jonathan Bluett-Duncan2017-08-09
| | | | | | | | | | | - Use Java 8 idioms more consistently. - Use newer Guava idioms more consistently. - Apply some IntelliJ IDEA refactoring suggestions. - Other changes made for readability and/or brevity. Closes #3462. PiperOrigin-RevId: 164700946
* Migrate the options parser to java8 functions.Gravatar ccalvarin2017-07-26
| | | | PiperOrigin-RevId: 163124023
* Make the @Option annotation depend on the java version of the tagging enums.Gravatar ccalvarin2017-07-18
| | | | | | | 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
* Fold OptionUsageRestrictions into OptionDocumentationCategory and ↵Gravatar ccalvarin2017-07-11
| | | | | | | | | | 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
* Allow expansion flags to have values.Gravatar Googler2017-06-28
| | | | | | | 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
* Fix printing of options categories in CLI helpGravatar brandjon2017-05-09
| | | | | | | Before it was omitting category titles / section breaks if the first option of the new category happened to be undocumented. RELNOTES: None PiperOrigin-RevId: 155458981
* Add a way for options classes to mark that they are skyframe-friendlyGravatar brandjon2017-04-27
| | | | | | | 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
* Add a way of constructing OptionsBase subclass instances from mapsGravatar brandjon2017-04-20
| | | | | | | Added toMap()/fromMap() to OptionsParser, and moved the implementation of OptionsBase#asMap away from OptionsParserImpl. RELNOTES: None PiperOrigin-RevId: 153602479
* Deprecate use of option category to describe documentation level / usage ↵Gravatar ccalvarin2017-04-19
| | | | | | | | 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
* Eliminate some middleman methodsGravatar brandjon2017-04-18
| | | | | | | | | Reduce spaghetti code by exposing the parser's OptionsData as package-private, rather than exposing individual methods ad hoc between OptionsParser and OptionsParserImpl. Also change some calls from static constructors to diamond syntax. RELNOTES: None PiperOrigin-RevId: 153457442
* Remove the overloading of option category to cover documentation level.Gravatar ccalvarin2017-04-18
| | | | | | | | 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
* Fix an expansion flag issue where it expands to a repeatable flag.Gravatar ccalvarin2017-04-18
| | | | | | | | There's no reason an expansion flag should not expand to multiple values for a repeatable flag (a flag with allowMultiple set to true.) If this expansion flag is set in a SetValue policy, group its repeatable subflags into a single SetValue per subflag. For an overridable SetValue policy on an expansion, any repeatable flag that it expands to should append its value, and not override the user's original values. PiperOrigin-RevId: 153233784
* Clean up clearValue and parsed option storage.Gravatar ccalvarin2017-04-05
| | | | | | | | | | Now that policy expands itself before being applied, clearValues never has to clear more than a single value. This makes that more clear. OptionValueDescription had not been consistently storing the snake_case name for an option, leading to some weird behavior when removing the map of return values from clearValues. PiperOrigin-RevId: 152156746
* Add --all_incompatible_changes, the user's shorthand for turning on all ↵Gravatar brandjon2017-04-03
| | | | | | | | | | | | --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
* Add new exception for wrapping parser construction failuresGravatar brandjon2017-04-03
| | | | | | | | | | The exception is unchecked. The reasoning is that errors during parser construction should not occur, and when they do occur it is an internal error like a failed assertion. This allows casual uses of the options parser to stay oblivious to the possibility of failures, consistent with how DuplicateOptionDeclarationException is currently [not] handled. At the same time, the dispatcher can catch the exception to fail gracefully (by printing to stdout instead of a log file) when parser construction fails for any reason. RELNOTES: None PiperOrigin-RevId: 151839620
* Expand Invocation FlagPolicies on expansion flags.Gravatar ccalvarin2017-03-31
| | | | | | | | For SetValue and UseDefault policies on expansion flags or flags with implicitRequirements, expand the policy into policy for each of its sub-flags. For SetValue, this addresses the issue with policies on expansion flags with overridable=true not actually letting user flags overrride the expansion. For UseDefault, this formalizes the behavior where UseDefault will wipe all user-provided flags that expand from a banned expansion flag, and will allow later work to guarantee that a later policy can override the expansion policy's subflags. Since expansion flags do not have value, break if the invocation policy uses AllowValue or DisallowValue on an expansion flag. PiperOrigin-RevId: 151718539
* Add expansion functions to options parserGravatar Jon Brandvein2017-03-22
| | | | | | | | | | | | 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
* Create "internal" category of command-line options.Gravatar Michael Staib2017-03-20
| | | | | | | | | | | | | | | | | | | | 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
* Remove duplicate class.Gravatar Chloe Calvarin2017-03-06
| | | | | | | | | | ParsedOptionEntry and OptionValueDescription were redundant and error-prone, since converting from one to the other involved adding a name that could easily be unrelated to the option value described. -- PiperOrigin-RevId: 149111525 MOS_MIGRATED_REVID=149111525
* Enable parameter file support for excessively long commandlines.Gravatar Googler2017-01-25
| | | | | | -- PiperOrigin-RevId: 145473123 MOS_MIGRATED_REVID=145473123
* The help command can now output html for the command-line reference page.Gravatar Ulf Adams2016-06-22
| | | | | | | An upcoming change will pipe this to an actual page. -- MOS_MIGRATED_REVID=125545220
* Fix OptionsParserImpl.clearValue (and invocation policy by extension) to workGravatar Alex Humesky2016-05-10
| | | | | | | correctly with flags that have expansion flags or implicit requirements. -- MOS_MIGRATED_REVID=121862297
* Memoize the OptionsData per BlazeCommand.Gravatar Nathan Harmata2016-05-02
| | | | | | | | | This saves the cost of (1) collecting all Options classes and (2) getting all their @Option annotations. Note that there is no savings on reflection costs, since that's already memoized internally by OptionsParser. This saves ~250us per Blaze invocation. -- MOS_MIGRATED_REVID=121153156
* Add explicit type arguments to unbreak java7 builds.Gravatar Janak Ramakrishnan2016-03-24
| | | | | -- MOS_MIGRATED_REVID=118042058
* Always apply invocation policy when constructing build options.Gravatar Janak Ramakrishnan2016-03-24
| | | | | -- MOS_MIGRATED_REVID=117939121
* Problem:Gravatar Googler2016-02-25
| | | | | | | | | | | | | | | The --help option is currently broken when allow residue is false as the --help option cannot be parsed and results in exit(2) after emitting the unhelpful message: Error parsing command line: Unrecognized option: --help Try --help. In this case, --help is never reached, and so cannot be used. Solution: In the proposed code, if any argument is --help, the --help message will be preferred over emitting parsing errors. The process will now exit(0) prior to parsing any other arguments if --help is passed. -- MOS_MIGRATED_REVID=115495600
* Adds support for invocation policy to the canonicalize-flags command.Gravatar Alex Humesky2016-01-15
| | | | | -- MOS_MIGRATED_REVID=112267123
* Adds a mechanism for invocation policy. The policy is taken through the ↵Gravatar Alex Humesky2015-09-30
| | | | | | | --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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 08:23:15 +0000