| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 179588174
|
| |
|
|
|
|
|
|
|
| |
allowMultiple=true
Was filtering for the implicit options in SingleOptionValue, but forgot the check in RepeatableOptionValue. This is now fixed.
RELNOTES: None.
PiperOrigin-RevId: 176669853
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
--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
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
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
|
ccalvarin