aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/common
Commit message (Collapse)AuthorAge
* Make option conflicts less spammy.Gravatar ccalvarin2017-10-16
| | | | | | | 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
* Expand implicitRequirements in the location of the option that required it.Gravatar ccalvarin2017-10-13
| | | | | | | | | | | 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
* Clean up InvocationPolicy's use of OptionDescription.Gravatar ccalvarin2017-10-11
| | | | | | OptionDescription is basically a hack to get the expansion data for options from outside the options parser, but it was being used at various points of invocation policy enforcement. In order to correctly track option origin, we only want to get this information once. Do it during the invocation policy expansion stage, not at enforcement, so that we track the information of the option's origin in the original invocation policy passed to the enforcer, not the expanded one. PiperOrigin-RevId: 171661669
* Report the structured Bazel command line via the BEP.Gravatar ccalvarin2017-10-10
| | | | | | | | | 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
* Downgrade the default invocation policy log levels to fine.Gravatar ccalvarin2017-10-06
| | | | | | | | Unfortunately, since the invocation policy gets enforced on a user's command line early in the command environment setup, so the effective log level is not yet set. For this run, keep the logs at INFO, since any other level will disappear into the ether. InvocationPolicy gets enforced not only at invocation startup but also elsewhere to recompute the default values. The log statements from these different runs overwhelm the log output from our tests, making it hard to find other events without filtering the log. Make all extra invocation policy enforcements log at FINE so that they only appear when extra detail is requested. PiperOrigin-RevId: 171151573
* Categorize build options for BuildConfiguration.Gravatar gregce2017-10-06
| | | | PiperOrigin-RevId: 171017483
* Add new option categorization and tagging information to HelpCommand's output.Gravatar ccalvarin2017-09-27
| | | | | | | | | | | | | 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
* Move the canonicalization of an option value to the option value itself.Gravatar ccalvarin2017-09-27
| | | | | | | 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
* Track the origin of an option in the option instance, not its final value.Gravatar ccalvarin2017-09-21
| | | | | | | | | 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
* Deprecate wrapperOptions.Gravatar ccalvarin2017-09-21
| | | | | | | In order to discourage new uses (there shouldn't be any, but just in case), make it illegal to set wrapperOption=true for non deprecated options. RELNOTES: None. PiperOrigin-RevId: 169477990
* Track all option instances.Gravatar ccalvarin2017-09-21
| | | | | | | 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
* Cleanup of expansion option namingGravatar ccalvarin2017-09-21
| | | | | | | | | 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
* Create multiple ParamsFilePreProcessors to allow parsing files using the ↵Gravatar apell2017-09-21
| | | | | | | formats specified in ParameterFile.ParameterFileType. Also maintain the currently used parsing style of whitespace split arguments that allows single and double quoting and whitespace and quote escaping. This style of parsing is for a format not currently generated and will be removed once all consuming actions have been converted to using a supported format explicitly. RELNOTES: None. PiperOrigin-RevId: 169437362
* Document the options in smaller commands.Gravatar ccalvarin2017-09-20
| | | | | RELNOTES: None. PiperOrigin-RevId: 169258065
* Treat parsed option values differently by option type.Gravatar ccalvarin2017-09-19
| | | | | | | | | | | | | | | | 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
* Throw away the confusing UnparsedOptionValueDescription name.Gravatar ccalvarin2017-09-18
| | | | | | | | | | | | | | 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
* Introduce "bazel help flags-as-proto" to print information about supported ↵Gravatar fwe2017-09-14
| | | | | | flags as a text protobuf. PiperOrigin-RevId: 168695297
* Pass the UnparsedOptionValues when setting or adding option values.Gravatar ccalvarin2017-09-14
| | | | | | | | 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
* Consolidate the "unparsed" option value tracking.Gravatar ccalvarin2017-09-14
| | | | | | | 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
* Move option value tracking classes to their own file.Gravatar ccalvarin2017-09-13
| | | | | | | 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
* Replace referrals to options by their name to option definitions.Gravatar ccalvarin2017-09-12
| | | | | | | 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
* Option value tracking should refer to the option definitions, not just track ↵Gravatar ccalvarin2017-09-11
| | | | | | | | | | | 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
* Options with oldNames will no longer get reported twice in the effective ↵Gravatar ccalvarin2017-09-11
| | | | | | | | | | 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
* More BUILD file refactorings.Gravatar philwo2017-09-06
| | | | | | | | | Split collect, concurrent, vfs, windows into package-level BUILD files. Move clock classes out of "util", into their own Java package. Move CompactHashSet into its own Java package to break a dependency cycle. Give nestedset and inmemoryfs their own package-level BUILD files. PiperOrigin-RevId: 167702127
* Expansion flags need some restraints.Gravatar ccalvarin2017-09-06
| | | | | | | | How expanding flags interact with other possible flag qualities is not defined. Should repeated values have effects multiple times and accumulate? This doesn't really make sense, expansion flags don't have values that would accumulate. For this reason, don't allow expansion options to have allowMultiple set to true. Likewise for other behaviors. PiperOrigin-RevId: 167580641
* Rename all logger instances to "logger" (instead "LOG" or "log").Gravatar lberki2017-09-05
| | | | | RELNOTES: None. PiperOrigin-RevId: 167505493
* Update comments about the option processor.Gravatar ccalvarin2017-09-01
| | | | | | | There were a few places where the current state of the world was not clear. RELNOTES: None. PiperOrigin-RevId: 167273651
* Move final static option checks to compile time.Gravatar ccalvarin2017-09-01
| | | | | | Check that the option has a non-empty name and that it does not use deprecated categories. While we're at it, check that the names for options that are flags (all but INTERNAL flags, which are not meant to be used on the command line) are sensible. PiperOrigin-RevId: 167182172
* Move caching of OptionDefinitions to be static, and remove uncached ↵Gravatar ccalvarin2017-09-01
| | | | | | | | | | 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
* Move static converter legality checks to compile time.Gravatar ccalvarin2017-08-31
| | | | | | | | | | | The information about whether a converter correctly matches the type of option it is meant to convert strings to is available at compile time. There is no reason to do this check at runtime. Now, for an option to compile, it will need to have a converter that matches the option's type, taking into account whether the option is expected to accumulate multiple values. If it does not specify its own converter, a matching converter in the Converters.DEFAULT_CONVERTER list must be found, and the default value provided must be parseable by the matching default converter. Remove tests that were testing failure modes which no longer compile. RELNOTES: None. PiperOrigin-RevId: 167092773
* Move default value & converter finding logic to the OptionDefinition class.Gravatar ccalvarin2017-08-30
| | | | | | | | | | | 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
* Rollforward of ↵Gravatar apell2017-08-29
| | | | | | | | | https://github.com/bazelbuild/bazel/commit/0071b396776be4d146fd271499716dd5dea6f7e9: Enable parameter files for manifest merger actions. NEW: Using shell quoted param files and unescape arguments in ParamsFilePreProcessor to avoid miss-processing --manifestValues arguments containing whitespace. RELNOTES: None. PiperOrigin-RevId: 166858411
* Refactoring: OptionsParser now uses the visitor pattern to iterate over ↵Gravatar fwe2017-08-28
| | | | | | | | | Blaze options. This change is in preparation for unknown commit which also needs to iterate over all options, but has to execute a different action than getOptionsCompletion(). As a result, applying the visitor patterns helps to avoid duplicate iteration code. PiperOrigin-RevId: 166515117
* Move option tag checks to compile time.Gravatar ccalvarin2017-08-25
| | | | | | | The rationality checks failed as RuntimeExceptions that weren't getting reported properly because the options parser is created too early in Bazel's lifetime to be reported properly to standard error. This was a minor annoyance for authors of new options, and there was nothing gained by waiting until runtime to check these values. RELNOTES: None PiperOrigin-RevId: 166395759
* Move compile-time checks to own package.Gravatar ccalvarin2017-08-24
| | | | | | | Didn't think it was worth it for a single file, but will be adding a processor for the UsesOnlyCoreTypes anontation as well. RELNOTES: None. PiperOrigin-RevId: 166341727
* Check at compile time that all options are declared public, and are ↵Gravatar ccalvarin2017-08-24
| | | | | | | | non-final and non-static. Remove the now redundant check in the testing framework, as the cases being tested no longer compile. Keep tests that check the contents of the OptionsBase as a whole, however, as this is still not being tested at compile time. PiperOrigin-RevId: 166239209
* Adding compile time checks to the options parser.Gravatar ccalvarin2017-08-23
| | | | | | | Keeping this simple for now, just checking that the options are declared in accepted places. Will convert static, annotation-content based checks to be done here instead of at runtime in a later change. TESTED: Added an option in a non-OptionBase, and verified that it failed to compile. PiperOrigin-RevId: 166126408
* Add OptionDefinition layer between the @Option annotation and its fields and ↵Gravatar ccalvarin2017-08-22
| | | | | | | | | | | 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
* Switch android tools' use of options parser to a more concise form for the ↵Gravatar ccalvarin2017-08-21
| | | | | | | | | | | single options-base case. This is to prepare the options parser from making options parser creation exceptions a caught exception. Since all of these classes already have a single options class and used parseAndExitUponError, this allows us to keep behavior consistent between the malformed options-base errors and the incorrect user-input errors. All the other uses of the options parser in //src/tools already throw sufficiently broad exceptions to not need this. RELNOTES: None PiperOrigin-RevId: 165702786
* Fix expansion option output formatting in html outputGravatar ccalvarin2017-08-18
| | | | | | 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
* Categorize query options.Gravatar janakr2017-08-18
| | | | PiperOrigin-RevId: 165581746
* Fix terminal output expansion flag spacing & add implicit requirements.Gravatar ccalvarin2017-08-17
| | | | | | | 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
* Use cached values for option converter types.Gravatar ccalvarin2017-08-16
| | | | | | 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
* PolishingGravatar Jonathan Bluett-Duncan2017-08-09
| | | | | | | | | | | - 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
* Accept expansion flags expanding to expansion flags in invocation policy.Gravatar ccalvarin2017-08-03
| | | | | | | Fix bug where a null value in the expansion text lead to a NullPointerException. RELNOTES: None. PiperOrigin-RevId: 164061496
* Migrate the options parser to java8 functions.Gravatar ccalvarin2017-07-26
| | | | PiperOrigin-RevId: 163124023
* Move the DurationConverter to the common.options packageGravatar ulfjack2017-07-24
| | | | | | | Also change it to java.time.Duration, rather than Jodatime. Now that we're on Java 8, we no longer need Jodatime. PiperOrigin-RevId: 162917526
* Add test framework for OptionsBase classes and their Converters.Gravatar mstaib2017-07-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because OptionsBase implements equals() as a final method, subclasses can only add fields in certain ways for OptionsBase to properly obey equals() semantics. Specifically, all fields must be public and @Option annotated. The OptionsTester checks for these two things. Additionally, Converters must make sure to always return equals() values on equals() (or equivalent) input. The OptionsTester includes a check that all Converters named by the OptionsBase subclass being tested have matching ConverterTesters, and if valid default values are specified (i.e., on Options which are not multi-valued or default null), that these defaults are among the values tested by the ConverterTesters. The ConverterTesters themselves are wrapped EqualsTesters, testing that the output of a Converter obeys equals() as expected for the same input (or equivalent ones), and is consistent across calls to the same Converter instance or different Converter instances. Between these two, OptionsBase subclasses can have reasonable certainty that two instances of themselves which were parsed equally - or underwent equivalent transformations - will be equal. This does not actually test any OptionsBase subclasses or Converter implementations; it merely adds a framework. Future changes will cover automatically testing all of the OptionsBase subclasses in a RuleClassProvider, but naturally, this requires writing test data for each Converter in the Bazel codebase first. RELNOTES: None. PiperOrigin-RevId: 162522445
* Split invocation policy from the optionsparser target.Gravatar ccalvarin2017-07-19
| | | | | | //src/main/java/com/google/devtools/common/options:options is now free of bazel protos, once again. PiperOrigin-RevId: 162385612
* Make the @Option annotation depend on the java version of the tagging enums.Gravatar ccalvarin2017-07-18
| | | | | | | 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-14 02:50:42 +0000