aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/common
Commit message (Collapse)AuthorAge
* 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
* Add the option filter enums in java, with equivalence check.Gravatar ccalvarin2017-07-17
| | | | | | | | | | In order to break out the proto dependency of the OptionsParser, add a java-only enum that users of the options parser can depend on, instead of requiring the dependency on the protobuf. The protocol buffer definition is kept in order to be used for command line reporting in the BEP, so a test is added to make sure that the two are kept in sync. Also add some clearer guidance for how to go about selecting, and adding, option categories and tags. Migrating the current uses of the proto enum to this one will happen in a follow-up change. PiperOrigin-RevId: 161971077
* First pass of @Option documentation for apple/objc/swiftGravatar cparsons2017-07-13
| | | | | RELNOTES: None. PiperOrigin-RevId: 161720296
* Fix options parsing javadoc typo.Gravatar gregce2017-07-11
| | | | PiperOrigin-RevId: 161520675
* Fold OptionUsageRestrictions into OptionDocumentationCategory and ↵Gravatar ccalvarin2017-07-11
| | | | | | | | | | OptionMetadataTags. These are similar, no need to have both fields. Removing the "DOCUMENTED" default, the absence of UNDOCUMENTED will be used instead. Since requiring a documentation category for undocumented options doesn't make sense, list that as one of the OptionDocumentationCategories, but list HIDDEN and INTERNAL as part of OptionMetadata. These options should list UNDOCUMENTED as their category. PiperOrigin-RevId: 161515674
* Enforce the new category and effect tags.Gravatar ccalvarin2017-07-03
| | | | | | | | | | All options need to explicitly list their category and effect. If they are uncategorized, this makes the lack of information obvious. Remove defaults from the annotation to enforce this. Also enforce the sanity check that no option should have UNKNOWN or NO_OP effects listed with other effect tags. Includes some last default sets for options I missed in the previous mass-setting change, and some that were added since. PiperOrigin-RevId: 160641861
* Allow expansion flags to have values.Gravatar Googler2017-06-28
| | | | | | | 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
* Add option tagging and categorizing enums.Gravatar ccalvarin2017-06-27
| | | | | | | | | | | | | | Begin work of transferring option categorization to a sustainable, documented setup. DocumentationCategories will replace the existing string category field, and will group flags in generated documentation. Each flag must belong to exactly 1 DocumentationCategory, whichever is most applicable or a new one. OptionEffectTags will document the effects of tags and will be used for filtering flags. These tags, unlike the categories, should be complete. All options that do affect Bazel's output should be tagged as affecting Bazel's output, for example. This is necessary for them to be useful when trying to isolate the cause of an issue or behavior by allowing irrelevant options to be filtered out. Each flag must have at least 1 intended behavior, so should have 1+ OptionEffectTag. If no effect tag applies, find a general tag that would apply and add it to all relevant options. OptionMetadataTags will hold information about the flag itself. Information about the lifecycle of a flag, for example, should belong in an OptionMetadataTag. It is useful for filtering, since it describes how trustworthy we might think the flag would be, but does not actually describe the “intent” or “meaning” of a flag. This can be an empty list, but options can also have multiple OptionMetadataTags All options will be switched from the old "category" field to this new system. A few general OptionsBases are provided as an example. PiperOrigin-RevId: 160180328
* Move InvocationPolicy to the options parser package.Gravatar ccalvarin2017-06-09
| | | | | | | | | | | | | | It was originally included in runtime due to external dependencies, and a desire to keep the options parser a general options library. These dependencies have been or will be removed, and there are plenty of other general flag libraries. InvocationPolicy is fundamentally acting on the properties of this specific OptionsParser and needs proper access to it for the proper solution to a number of existing bugs, which means having access to things that should be package private. PiperOrigin-RevId: 158523111
* Use ImmutableList for Option expansion functionsGravatar Googler2017-06-08
| | | | | RELNOTES: None PiperOrigin-RevId: 158279811
* Require that flags with static expansions be of Void type.Gravatar ccalvarin2017-06-07
| | | | | | | The type was ignored, and it was expected that all expansion flags had no value of their own, but was not checked. PiperOrigin-RevId: 158261788
* Internal changeGravatar Googler2017-06-05
| | | | PiperOrigin-RevId: 157878648
* Remove support of --no_ prefix for boolean flags.Gravatar ccalvarin2017-06-01
| | | | | | | | The no_ prefix was initially undocumented, but its support has over time lead to a number of inconsistencies. RELNOTES: --no_ prefix no longer recognized. PiperOrigin-RevId: 157631435
* Fix printing of options categories in CLI helpGravatar brandjon2017-05-09
| | | | | | | Before it was omitting category titles / section breaks if the first option of the new category happened to be undocumented. RELNOTES: None PiperOrigin-RevId: 155458981
* Add a way for options classes to mark that they are skyframe-friendlyGravatar brandjon2017-04-27
| | | | | | | You can now use the annotation @UsesOnlyCoreTypes on a subclass of OptionsBase, to indicate that all of its options' types are restricted to a whitelist of immutable and serializable types. Subclasses of the annotated class must also follow the same restriction. RELNOTES: None PiperOrigin-RevId: 154328920
* Don't hard remove --no_, give a warning first.Gravatar ccalvarin2017-04-20
| | | | PiperOrigin-RevId: 153610163
* Add a way of constructing OptionsBase subclass instances from mapsGravatar brandjon2017-04-20
| | | | | | | Added toMap()/fromMap() to OptionsParser, and moved the implementation of OptionsBase#asMap away from OptionsParserImpl. RELNOTES: None PiperOrigin-RevId: 153602479
* Deprecate use of option category to describe documentation level / usage ↵Gravatar ccalvarin2017-04-19
| | | | | | | | restrictions. Prevent the old category strings "undocumented," "hidden," or "internal" from being used as categories, to prevent developers from relying on deprecated behavior. PiperOrigin-RevId: 153525499
* Eliminate some middleman methodsGravatar brandjon2017-04-18
| | | | | | | | | 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
* Add ordering semantics for cached options dataGravatar brandjon2017-04-18
| | | | | | | 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
* Remove the overloading of option category to cover documentation level.Gravatar ccalvarin2017-04-18
| | | | | | | | This prevents having to parse the category, and allows the category to potentially be used in the future for information about all options, included undocumented, hidden, or internal options. Also rename DocumentationLevel to OptionUsageRestrictions, since INTERNAL was not really documentation related. PiperOrigin-RevId: 153367769
* Fix an expansion flag issue where it expands to a repeatable flag.Gravatar ccalvarin2017-04-18
| | | | | | | | There's no reason an expansion flag should not expand to multiple values for a repeatable flag (a flag with allowMultiple set to true.) If this expansion flag is set in a SetValue policy, group its repeatable subflags into a single SetValue per subflag. For an overridable SetValue policy on an expansion, any repeatable flag that it expands to should append its value, and not override the user's original values. PiperOrigin-RevId: 153233784
* Remove --no_ support.Gravatar ccalvarin2017-04-07
| | | | | --no_ prefixes for boolean flags are deprecated. Error out nicely if --no_ is supplied. PiperOrigin-RevId: 152434290
* Add integration test for --all_incompatible_changes flag conflictsGravatar brandjon2017-04-05
| | | | | | | | | | This adds a new warning when the same flag is expanded to by multiple expansion flags. This extends an existing suite of warnings, e.g. for when an expansion flag conflicts with an explicit option. The blaze canonicalize-flags command now takes a new flag --show_warnings. This flag causes any warnings encountered while parsing the given command line to be printed to stderr. RELNOTES: blaze canonicalize-flags now takes a --show_warnings flag PiperOrigin-RevId: 152186672
* Clean up clearValue and parsed option storage.Gravatar ccalvarin2017-04-05
| | | | | | | | | | Now that policy expands itself before being applied, clearValues never has to clear more than a single value. This makes that more clear. OptionValueDescription had not been consistently storing the snake_case name for an option, leading to some weird behavior when removing the map of return values from clearValues. PiperOrigin-RevId: 152156746
* Add --all_incompatible_changes, the user's shorthand for turning on all ↵Gravatar brandjon2017-04-03
| | | | | | | | | | | | --incompatible_* flags Note that if a developer adds a poorly-formatted incompatible change @Option, constructing an OptionsParser will now fail with an unchecked exception. This can cause some unit tests to fail in unexpected ways, but the developer should see an appropriate error message when the server starts up. To be added: A separate integration test that ensures the expansions of --all_incompatible_changes don't clobber each other. RELNOTES: None PiperOrigin-RevId: 151858287
* Add new exception for wrapping parser construction failuresGravatar brandjon2017-04-03
| | | | | | | | | | The exception is unchecked. The reasoning is that errors during parser construction should not occur, and when they do occur it is an internal error like a failed assertion. This allows casual uses of the options parser to stay oblivious to the possibility of failures, consistent with how DuplicateOptionDeclarationException is currently [not] handled. At the same time, the dispatcher can catch the exception to fail gracefully (by printing to stdout instead of a log file) when parser construction fails for any reason. RELNOTES: None PiperOrigin-RevId: 151839620
* Watch for --no and --no_ flag name conflicts.Gravatar ccalvarin2017-03-31
| | | | | | | | | Prevent OptionsBases with conflicting names due to --no boolean flag aliases to successfully combine into parser. Also remove the comment about --no_ not being documented, since it has been documented since Bazel was open-sourced. PiperOrigin-RevId: 151738453
* Expand Invocation FlagPolicies on expansion flags.Gravatar ccalvarin2017-03-31
| | | | | | | | For SetValue and UseDefault policies on expansion flags or flags with implicitRequirements, expand the policy into policy for each of its sub-flags. For SetValue, this addresses the issue with policies on expansion flags with overridable=true not actually letting user flags overrride the expansion. For UseDefault, this formalizes the behavior where UseDefault will wipe all user-provided flags that expand from a banned expansion flag, and will allow later work to guarantee that a later policy can override the expansion policy's subflags. Since expansion flags do not have value, break if the invocation policy uses AllowValue or DisallowValue on an expansion flag. PiperOrigin-RevId: 151718539
* Add expansion functions to options parserGravatar Jon Brandvein2017-03-22
| | | | | | | | | | | | 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
* Create "internal" category of command-line options.Gravatar Michael Staib2017-03-20
| | | | | | | | | | | | | | | | | | | | This is intended to be used for "flags" which should never appear on the command line - things like configuration distinguishers, which are used internally and must be part of the build options, but should always be set to their default value at the top level. This is already a convention within Bazel, but doesn't actually work the way Bazel expects - flags with spaces can be set by simply escaping or quoting the spaces so that word splitting will not break on them. This means they can also be matched by config_settings, which pass a single string. Forbidding the parser from matching these flags solves both of these unintended cases. Existing cases like this have also been converted to internal. -- PiperOrigin-RevId: 150497246 MOS_MIGRATED_REVID=150497246
* Refactor options converter logicGravatar Jon Brandvein2017-03-20
| | | | | | | | 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
* Remove duplicate class.Gravatar Chloe Calvarin2017-03-06
| | | | | | | | | | ParsedOptionEntry and OptionValueDescription were redundant and error-prone, since converting from one to the other involved adding a name that could easily be unrelated to the option value described. -- PiperOrigin-RevId: 149111525 MOS_MIGRATED_REVID=149111525
* Fix the OptionsParser to deal with CRLF line endings.Gravatar Googler2017-01-25
| | | | | | | | Fixes https://github.com/bazelbuild/bazel/issues/2416 -- PiperOrigin-RevId: 145595491 MOS_MIGRATED_REVID=145595491
* Enable parameter file support for excessively long commandlines.Gravatar Googler2017-01-25
| | | | | | -- PiperOrigin-RevId: 145473123 MOS_MIGRATED_REVID=145473123
* Rollback of commit e6191f7209ebf3f67480bc7aa9db5ac58beb2156.Gravatar Damien Martin-Guillerez2016-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Roll-forward with fix. Tested with `bazel build src:srcs //src/test/...` using a bootstrapped bazel. Fixes #1923. RELNOTES[INC]: Non test-only targets can no longer depends on test-only targets. *** Original change description *** Automated [] rollback of commit a9f20b0d6459d395444c45cf5e94a899f3443633. *** Reason for rollback *** Broke Bazel CI: ERROR: /home/ci/workspace/Bazel/JAVA_VERSION/1.8/PLATFORM_NAME/linux-x86_64/src/BUILD:284:1: in filegroup rule //src:srcs: non-test target '//src:srcs' depends on testonly target '//src/java_tools/junitrunner/java/com/google/testing/junit/junit4:srcs' and doesn't have testonly attribute set. ERROR: Analysis of target '//scripts/packages:packages' failed; build aborted. http://ci.bazel.io/view/Bazel%20b... *** -- MOS_MIGRATED_REVID=136589937
* Make --watchfs a common command option.Gravatar Ulf Adams2016-10-14
| | | | | | | | | | | | | | | | | | | | | | | | | Adding an options parameter to DiffAwareness#getCurrentView seems like the simplest way to achieve that. Alternatives considered: 1. Making the diff awareness modules stateful. However, I did not want to do so as I've also been working on improving the module API to reduce state, or at least to have a proper lifecycle management for any necessary state. 2. Making the watchFs flag a constructor parameter. However, that would also invalidate any implementations that don't use the flag (of which we have several). 3. Only passing in a single boolean flag instead of an options class provider; however, this is a more principled, futureproof API, which allows other modules / awareness implementations to use their own options. RELNOTES: --watchfs is now a command option; the startup option of the same name is deprecated. I.e., use bazel build --watchfs, not blaze --watchfs build. -- MOS_MIGRATED_REVID=136154395
* Rollback of commit 2891ec527eed27d0c6460d66f51cb66a43373b6a.Gravatar Damien Martin-Guillerez2016-10-14
| | | | | | | | | | | | | | | | | | | | | | | | | | *** Reason for rollback *** Causes our integration tests on Darwin to time out *** Original change description *** Make --watchfs a common command option. Adding an options parameter to DiffAwareness#getCurrentView seems like the simplest way to achieve that. Alternatives considered: 1. Making the diff awareness modules stateful. However, I did not want to do so as I've also been working on improving the module API to reduce state, or at least to have a proper lifecycle management for any necessary state. 2. Making the watchFs flag a constructor parameter. However, that would also invalidate any implement... *** -- MOS_MIGRATED_REVID=136070807
* Make --watchfs a common command option.Gravatar Ulf Adams2016-10-13
| | | | | | | | | | | | | | | | | | | | | | | | | Adding an options parameter to DiffAwareness#getCurrentView seems like the simplest way to achieve that. Alternatives considered: 1. Making the diff awareness modules stateful. However, I did not want to do so as I've also been working on improving the module API to reduce state, or at least to have a proper lifecycle management for any necessary state. 2. Making the watchFs flag a constructor parameter. However, that would also invalidate any implementations that don't use the flag (of which we have several). 3. Only passing in a single boolean flag instead of an options class provider; however, this is a more principled, futureproof API, which allows other modules / awareness implementations to use their own options. RELNOTES: --watchfs is now a command option; the startup option of the same name is deprecated. I.e., use bazel build --watchfs, not blaze --watchfs build. -- MOS_MIGRATED_REVID=136026835
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-05 06:14:07 +0000