| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
| |
Found by searching for TODOs mentioning "Java 7". There are plenty of other instances where we can simplify, but I don't want to be responsible for a large blast radius. At least in these cases we're fixing outdated comments.
RELNOTES: None
PiperOrigin-RevId: 161570189
|
|
|
|
|
|
|
| |
With a few manual fixes for readability.
RELNOTES: None.
PiperOrigin-RevId: 160582556
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=108243881
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=102332437
|
|
|
|
|
|
|
|
|
|
|
| |
three values for a given output formatter: 'no', 'deps', or 'full'. A fourth value, 'auto', means either 'deps' or 'full' depending on the formatter.
The option 'no' is equivalent to --noorder_results. 'full' means that output will be deterministically ordered, using alphabetization if necessary. 'deps' means that graph order will be preserved (where applicable), but further efforts to order the output may not be undertaken. 'auto' is equivalent to 'full' for all output formatters except for proto, minrank, maxrank, and graph, for which it is equivalent to 'deps'.
The purpose of this cl is to enable genquery to force completely deterministic output, which requires that it be able to specify a total ordering on the graph that is consistent across runs. Which ordering doesn't matter very much, so depending on the output formatter, or even within the same one, there may be some groups of nodes that are ordered alphabetically, and some reverse alphabetically.
--
MOS_MIGRATED_REVID=101512292
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=100985124
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=87821306
|
|
|
|
|
|
|
|
|
| |
This environment eagerly preloads the transitive closure of a specified query "universe", and so may not be as efficient as the standard query for limited-scope queries. It is activated when the universe is specified and ordered results are not requested (since it is currently unable to order results).
Tests were modified/added to exercise this environment where deemed interesting. Some ugly hacks were done to add coverage in AbstractQueryTest and friends, because currently even if the full depot is loaded (using //...), individual target patterns most likely won't be present in the graph. A better way to deal with this situation, suggested by felly, is probably to extract target pattern resolution logic to an auxiliary function so that query is able to resolve target patterns without mutating the graph, and then call into the read-only graph with the resolved patterns. That may be done in a follow-up, in which case the "scope" of every query could be //... .
--
MOS_MIGRATED_REVID=87257028
|
|
--
MOE_MIGRATED_REVID=85702957
|