| 195dd40824457bb0b3b934ec2c14ab36840f1ff0 |
|
16-Oct-2017 |
ccalvarin <ccalvarin@google.com> |
Track Option placement within a priority category.
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
/external/desugar/java/com/google/devtools/common/options/ParsedOptionDescription.java
|
| 2c2f636ed26b6cf80d2135f0d337e159e047e89d |
|
10-Oct-2017 |
ccalvarin <ccalvarin@google.com> |
Report the structured Bazel command line via the BEP.
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
GitOrigin-RevId: ceb1013c1ca0238188e2714442fcfb2efb16bc6a
Change-Id: I3a40b8e1ebd5d6a7d7e893be369d6d25de758ac7
/external/desugar/java/com/google/devtools/common/options/ParsedOptionDescription.java
|
| a0d433e79adbd70bc30ee613654fdf3fbb9de991 |
|
26-Sep-2017 |
ccalvarin <ccalvarin@google.com> |
Move the canonicalization of an option value to the option value itself.
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
/external/desugar/java/com/google/devtools/common/options/ParsedOptionDescription.java
|
| 05bb5c28c6be8320c06d8bb1bafd0be586678138 |
|
21-Sep-2017 |
ccalvarin <ccalvarin@google.com> |
Track the origin of an option in the option instance, not its final value.
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
/external/desugar/java/com/google/devtools/common/options/ParsedOptionDescription.java
|
| 2c366b859ba2c84184e38450786e33368c9c39c2 |
|
21-Sep-2017 |
ccalvarin <ccalvarin@google.com> |
Cleanup of expansion option naming
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
/external/desugar/java/com/google/devtools/common/options/ParsedOptionDescription.java
|
| cff0d218a8d061b3568a6197b8d456424d9c9c4a |
|
15-Sep-2017 |
ccalvarin <ccalvarin@google.com> |
Throw away the confusing UnparsedOptionValueDescription name.
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
/external/desugar/java/com/google/devtools/common/options/ParsedOptionDescription.java
|