summaryrefslogtreecommitdiff
path: root/java/com/google/devtools/common/options/OptionsParserImpl.java
AgeCommit message (Collapse)Author
2018-05-04Remove alphabetical sorting of options in the canonical list.ccalvarin
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 GitOrigin-RevId: aa98bc29dae14119797febd447302842f4ac68af Change-Id: I82fb65d38569d4e5a9808f032da1ccc2304e2f18
2018-05-04Warn about config expansions as we do for other expansions.ccalvarin
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 GitOrigin-RevId: 0421d7d8566a6fbe35e17a1edc3ab4d622aa6c9e Change-Id: Ie028995d2c4cbb90614ea8094b662d1b6e319241
2018-05-04Remove wrapper options support.ccalvarin
RELNOTES: None. PiperOrigin-RevId: 179588174 GitOrigin-RevId: 16f1c19c2c4f68555bb23891e3a4da4d5ac4a68d Change-Id: I089b4b2e4c846682db552aa4c0e0905142e9278b
2017-11-29Change config expansion application order, gated by startup flag ↵ccalvarin
--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 GitOrigin-RevId: 6364017ef95353969a8297c99a07c2a52102d9cc Change-Id: Id8b305db7a336132ee157cd0998330333888a139
2017-11-29Cleanup stream use in canonical list of options.ccalvarin
Follow up to https://github.com/bazelbuild/bazel/commit/c50cd13c75a2a1685f5ac9bd70561ac1e50722e7 RELNOTES: None. PiperOrigin-RevId: 174498205 GitOrigin-RevId: fecf464ec3bf2593e31fa6cd25a45ce149c2dd75 Change-Id: Ife1674dc14b8276510df9730e84416863b79a59f
2017-11-29Switch on tracking of specific option priorities.ccalvarin
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 GitOrigin-RevId: 4871bf7f50dc889985ae25102c3fb9de869b50bc Change-Id: Ieaa99adffd4d7f33167b18635641d4d3439d5a64
2017-11-29Compute canonical list of options using OptionValueDescription's tracking of ↵ccalvarin
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 GitOrigin-RevId: c50cd13c75a2a1685f5ac9bd70561ac1e50722e7 Change-Id: I9c6802dc3ab1e263048862f931f0c5f4933576ae
2017-10-24Track expansions in OptionValueDescription.ccalvarin
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 GitOrigin-RevId: 1a4f4264492a0b37a4132d629342aa961fa1c6b0 Change-Id: I7f125848d4ee9b56184f1ac46343187bd7b79ddf
2017-10-24Remove feature to allow expansion flags to have values.ccalvarin
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 GitOrigin-RevId: 34a9fea78f201caed8ace5c714a0cf288cb97c65 Change-Id: Ic26df46a5ff16f3b6dd89616ef9fcbe9a7971fa6
2017-10-24Track Option placement within a priority category.ccalvarin
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 GitOrigin-RevId: 7cd9e883dd31f54cd505844aa1f1e0ed7bd9f380 Change-Id: Ia0c09601ac24ffceb31e47b9113a636849c9b2f4
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-10-24Add new option categorization and tagging information to HelpCommand's output.ccalvarin
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 GitOrigin-RevId: 77e3a5ca955a3834406a837dbd4607b0b432b2d8 Change-Id: Id3f1fea6833f0cc05d127eb1454f21c92b22e03a
2017-10-24Move the canonicalization of an option value to the option value itself.ccalvarin
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 GitOrigin-RevId: 659feca7dee332f75801010b018505b7ba5a185e Change-Id: I65e969918c0ce0129d52e3fcdda4d95cde5175b7
2017-09-22Track the origin of an option in the option instance, not its final value.ccalvarin
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 GitOrigin-RevId: 3a0df3cb0637d71dfcf0add7057332c09cd508c5 Change-Id: Ic187397f8204aea3638b109b71d590920e968bdb
2017-09-22Track all option instances.ccalvarin
Regardless of option type, have the OptionValueDescription track information about the parsed option. This does not yet change the values that we output as part of the GotOptionsEvent, as the expansion, implicit req, and wrapper options still don't actually track anything in their option value. RELNOTES: None. PiperOrigin-RevId: 169469793 GitOrigin-RevId: 1ad38ea0dd4eb10cad92daf0fb2710ff118147c9 Change-Id: If2f29862ffabb190cbb9fcdc1a56685fa2916a5e
2017-09-22Cleanup of expansion option namingccalvarin
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 GitOrigin-RevId: 4acb36c048a620abd7a0f5dff274851bd6dd9c28 Change-Id: I75068dceefa40f56201d3b6817d551741137085d
2017-09-22Treat parsed option values differently by option type.ccalvarin
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 GitOrigin-RevId: 3ab171a1b03861d40fcf49fb56e2d8df87db25ab Change-Id: I2933cb6d69e3d5b3c605bc6d9308f8be84dd3714
2017-09-22Throw away the confusing UnparsedOptionValueDescription name.ccalvarin
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 GitOrigin-RevId: fb153cd83c6f801271048ec1d62d17a68562376d Change-Id: I90065b60724e698b93e685c045a21f901adb3c14
2017-09-22Pass the UnparsedOptionValues when setting or adding option values.ccalvarin
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 GitOrigin-RevId: a8c0c8dfad38437bc617b4b66d271bc0beb1b7c1 Change-Id: I159b1a1a076704bc3b90760b8c8ad628a135830a
2017-09-22Consolidate the "unparsed" option value tracking.ccalvarin
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 GitOrigin-RevId: 5fe8e6629e09ce44c6835d1b8f3a36bc3d69f131 Change-Id: I3964b563289ee39ab3a9a7ac496ed033459546c0
2017-09-22Move option value tracking classes to their own file.ccalvarin
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 GitOrigin-RevId: 7da54b5e2942bdb444abbf68ac3c7f34a453b4d9 Change-Id: I476d951094068ca828d3503c8c8af9dfe5648e5e
2017-09-12Replace referrals to options by their name to option definitions.ccalvarin
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 GitOrigin-RevId: 1dce09721f8361240bbf056fd508f1ac5fdcfd32 Change-Id: I5ca50358d96ed613c544248920ca51cbe856842e
2017-09-12Option value tracking should refer to the option definitions, not just track ↵ccalvarin
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 GitOrigin-RevId: 95c1ee3261c6cd2263a954dc45611248ca4d5ce7 Change-Id: I2e9c6fd2580fcdc3eec2795d8b9c0d95c05905b4
2017-09-12Options with oldNames will no longer get reported twice in the effective ↵ccalvarin
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 GitOrigin-RevId: 80399bc14ced39936ef19a20f3b8c2d1536aa6c2 Change-Id: Id2d7edfcace3f21b9ed4997fc9b94e4c39731a4a
2017-09-06Move caching of OptionDefinitions to be static, and remove uncached ↵ccalvarin
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 GitOrigin-RevId: 987f09f0cf3c5bf2fc5157c20fe0f7979978a40b Change-Id: I5ceeb8e2b12215f5702a8731b9a94b97bd48792a
2017-08-30Move default value & converter finding logic to the OptionDefinition class.ccalvarin
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 GitOrigin-RevId: 00443495e002c9fc68adbcb708f223eb4b6a73c1 Change-Id: If3915782a59d520353f3e5daeb4e489484a3307c
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-08-17Use cached values for option converter types.ccalvarin
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 GitOrigin-RevId: c69dbf8ed4893066d0474f87c0a8ddae00e4ee58 Change-Id: Iba12221dbcf759ab090c3c66509c89055e820fd1
2017-08-17PolishingJonathan Bluett-Duncan
- 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 GitOrigin-RevId: 0df3ddbdc289af97ffd2fb98197548f21b2c69a9 Change-Id: Ia18bac5af262592416cd560c60653c545b778882
2017-07-27Migrate the options parser to java8 functions.ccalvarin
PiperOrigin-RevId: 163124023 GitOrigin-RevId: 8ea7685bd4db755be6c600dc1f800fc0af3a9771 Change-Id: Ic9275baba5e9134adb75c608efa6579879a32e00
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-06-30Allow expansion flags to have values.Googler
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 GitOrigin-RevId: 7c7255ec8d6da20526c2c4078c57aadaf3dd3612 Change-Id: I4e6d8d79a13ea89329d52280958122fa01e91872
2017-06-16Use ImmutableList for Option expansion functionsGoogler
RELNOTES: None PiperOrigin-RevId: 158279811 GitOrigin-RevId: 69faad021dcf65d8f1967f26808c10f9f949ed7e Change-Id: I6f7b151936734e3efe457aab3d62188791b58ad5
2017-06-16Remove support of --no_ prefix for boolean flags.ccalvarin
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 GitOrigin-RevId: ca600bf2d014650b1f1ecb5214878b09a0838086 Change-Id: I2fb139e544049b153ab5a154a96f438e6d63d3e8
2017-04-27Don't hard remove --no_, give a warning first.ccalvarin
PiperOrigin-RevId: 153610163 GitOrigin-RevId: f9efa42113c5bcf0aaadb73fbc3822b389cc5c96 Change-Id: Id19ba95070a42d783154732bbd50daa9d147d440
2017-04-27Add a way of constructing OptionsBase subclass instances from mapsbrandjon
Added toMap()/fromMap() to OptionsParser, and moved the implementation of OptionsBase#asMap away from OptionsParserImpl. RELNOTES: None PiperOrigin-RevId: 153602479 GitOrigin-RevId: 4c2c4284b6f72adf9042d3e9e24dde46c32d16e2 Change-Id: I0d80e1874b0ad417115dae2f300639a431409416
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-18Eliminate some middleman methodsbrandjon
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 GitOrigin-RevId: d1b34d487bb83f0761d707cb8b27f88d547068e8 Change-Id: Ib85e12615e6215b7ee8ff341bc35e32e36486353
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-04-18Remove --no_ support.ccalvarin
--no_ prefixes for boolean flags are deprecated. Error out nicely if --no_ is supplied. PiperOrigin-RevId: 152434290 GitOrigin-RevId: 681f433545a22c8169bed8643fee560f3b500607 Change-Id: I3cd83e889daedf3c7964bd0b0a1bc62f7ad71cee
2017-04-05Add integration test for --all_incompatible_changes flag conflictsbrandjon
This adds a new warning when the same flag is expanded to by multiple expansion flags. This extends an existing suite of warnings, e.g. for when an expansion flag conflicts with an explicit option. The blaze canonicalize-flags command now takes a new flag --show_warnings. This flag causes any warnings encountered while parsing the given command line to be printed to stderr. RELNOTES: blaze canonicalize-flags now takes a --show_warnings flag PiperOrigin-RevId: 152186672 GitOrigin-RevId: e11775c2394fc48ac7fe5b632b47ae952dd552b4 Change-Id: Id14310d27000d5c7cbe6fe4ec236c3591b9ff1be
2017-04-05Clean up clearValue and parsed option storage.ccalvarin
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 GitOrigin-RevId: 0e02f53599487ef44188cfad3c0115261d7cc993 Change-Id: Ia2665ea44b4fe78c24e6c477017a4f492ac8a2d6
2017-04-05Watch for --no and --no_ flag name conflicts.ccalvarin
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 GitOrigin-RevId: 584dc717e64df4e50d7f657eb2878f53295eab12 Change-Id: I9c7bf47ac2135df2626ce80e4b9e82500f1d5f53
2017-04-05Expand Invocation FlagPolicies on expansion flags.ccalvarin
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 GitOrigin-RevId: 706bafe7aa17ed6ef1187986af3ba749559fb232 Change-Id: I75e326362f23733f0cf1df4d12c0c0b107b6e813
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-03-22Refactor options converter logicJon Brandvein
Moved default converters from parser implementation to Converters. Moved other helpers to OptionsData. Also factored out new function getFieldSingularType. -- PiperOrigin-RevId: 150473455 MOS_MIGRATED_REVID=150473455 GitOrigin-RevId: 097e64c412c6a4162a22880fd435ef4632878406 Change-Id: Ife5702b6f39415a7df3fd8b44c1867145a6ac466
2017-03-13Remove duplicate class.Chloe Calvarin
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 GitOrigin-RevId: 7579e1487f02bf97c7c68781d2f1007c54f961ab Change-Id: I3c76408de02ed250a1f3b47920af9af4d735b7d5
2017-02-16Enable parameter file support for excessively long commandlines.Googler
-- PiperOrigin-RevId: 145473123 MOS_MIGRATED_REVID=145473123 GitOrigin-RevId: 3f06748eb6c4fe1a8d30aae118f37885c23ec984 Change-Id: Ibf5d53f6f74d3d1768424100def49fdecd3cfbaa
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-17 07:43:56 +0000