| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 158279811
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This lets us easily get all options classes of a parser, or all fields of those options classes, in a deterministic way.
RELNOTES: None
PiperOrigin-RevId: 153376699
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
- change options to print --foo=value
- allow option to specify what "value" should be
- update the documentation for the startup options
- add some indentation to the descriptions
- add some spacing between flag texts
--
MOS_MIGRATED_REVID=125960618
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=125665042
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=125662988
|
| |
|
|
|
| |
--
MOS_MIGRATED_REVID=125568305
|
| |
|
|
|
|
|
| |
An upcoming change will pipe this to an actual page.
--
MOS_MIGRATED_REVID=125545220
|
| |
|
|
|
|
|
|
|
|
|
| |
The headers were modified with
`find . -type f -exec 'sed' '-Ei' 's|Copyright 201([45]) Google|Copyright 201\1 The Bazel Authors|' '{}' ';'`
And manual edit for not Google owned copyright. Because of the nature of ijar, I did not modified the header of file owned by Alan Donovan.
The list of authors were extracted from the git log. It is missing older Google contributors that can be added on-demand.
--
MOS_MIGRATED_REVID=103938715
|
| |
|
|
|
|
|
|
|
|
| |
`bazel help completion` dump all options completion pattern
for each command, giving hints on the format of the completion
residue (e.g., `label`, `path`, `{a,enum}`, ...). This
dump can be used to generate completion scripts.
--
MOS_MIGRATED_REVID=90743024
|
|
|
--
MOE_MIGRATED_REVID=85702957
|
ccalvarin
Jonathan Bluett-Duncan
Googler
brandjon
Ulf Adams
Damien Martin-Guillerez
Han-Wen Nienhuys