| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
GitOrigin-RevId: 62f72bce464cf896dfb64096d151a0293ad70345
Change-Id: I09cb723d8b71e6ea6a645ac6ce2a3391e4024988
|
|
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
GitOrigin-RevId: c65147b4bb866bd8ec553dcbec5e9bb59c164493
Change-Id: I9ff89fdb3809bc55e93bd3cfdea30838b55d6078
|
|
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
|
|
- 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
|
|
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
|
|
RELNOTES: None
PiperOrigin-RevId: 158279811
GitOrigin-RevId: 69faad021dcf65d8f1967f26808c10f9f949ed7e
Change-Id: I6f7b151936734e3efe457aab3d62188791b58ad5
|
|
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
|
|
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
GitOrigin-RevId: 91e4dedd402c214a815eb6e2290998dec1f3d397
Change-Id: I9570bd2389ff177f014b86928bcb3194f3175049
|
|
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
|
|
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
|
|
- 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
GitOrigin-RevId: 6f09666d994b3bd7663eb3f95e2aeaf63c85b0d7
Change-Id: I228f26ed2cedf219ab1d32befde8ba765f33fc5a
|
|
--
MOS_MIGRATED_REVID=125665042
GitOrigin-RevId: 65c3e36d41f5682a2c3cf6e77c88bd08a86b9670
Change-Id: I4206b359b6197c6a476e0afc0e4489c34e6bab23
|
|
--
MOS_MIGRATED_REVID=125662988
GitOrigin-RevId: e7598d1ec99f489d2126fa49f057c9e5bcb15d04
Change-Id: I040dfa8732bffba0d567a9d697da7b39df9b173a
|
|
--
MOS_MIGRATED_REVID=125568305
GitOrigin-RevId: dba6223afff671df63901814c7424dc7a7243004
Change-Id: I1b142ca135b47abdc717d0db1e44f738c80c6369
|
|
An upcoming change will pipe this to an actual page.
--
MOS_MIGRATED_REVID=125545220
GitOrigin-RevId: 352211d7662490ae87115f761aa4cc1e08142529
Change-Id: If3dd9fd0afeeecfab5b8d70037e277b6dfea9fa4
|
|
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
GitOrigin-RevId: f88f4d81acead9ef3e2f73d9a44afd76c2c239c1
Change-Id: I24bf6dcdbf1c77ea6ae5eaef65072ec9727d6fb7
|
|
`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
GitOrigin-RevId: 29728d4c37721aa88621a8578a7c2d7bfe8b5c68
Change-Id: Id4ce5e3f3efa0b8c4e70a77e5fa745d3e978efe5
|
