| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
Please refer to patch set 9 and its CI run for usage and test
results. In practice, users should create their own java_toolchain
rule in their project's BUILD file, and set the two attributes like
above instead of modifying //tools/jdk/BUILD.
Change-Id: Ic880f243086b00a58d453a8139ba4c957fe54bc7
PiperOrigin-RevId: 159694649
|
|
|
|
|
|
| |
This makes the URIs absolute, which makes them easier to process server-side.
PiperOrigin-RevId: 159694335
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR #2679 allowed parentheses ("(" and ")") in globs, but other bracket
style characters were not allowed at the time. It was decided in
issues #2583 and #3048 that other bracket characters should be allowed
as well, since there is no apparent historical reason for disallowing
them in the first place.
Closes #3166.
PiperOrigin-RevId: 159691498
|
|
|
|
|
|
|
|
| |
This will allow us to add new and optional flags like selecting a strategy used to spawn / wait for the child process.
No one except Bazel should be calling "process-wrapper" and I couldn't find any references, so this breaking change should be fine.
PiperOrigin-RevId: 159685867
|
|
|
|
|
|
|
|
| |
The "is is line with" should read "is in line with". While there,
also fix the formating of that comment.
RELNOTES: None.
PiperOrigin-RevId: 159683437
|
|
|
|
|
|
| |
used wait_for_completion field.
Change-Id: I83a16d22f49c44989ec7030b5d2c9c9b1387e6e0
|
|
|
|
|
|
|
|
|
|
| |
This cl finishes the last bit of c++ linking actions migration to crosstool's
action_configs. From now on, the action_config { tool_path: ... } will be used,
instead of top level tool { path: ... }.
RELNOTES: Bazel now uses tools from action_configs in Crosstool by default (as
oposed to using top level tools).
PiperOrigin-RevId: 159677525
|
|
|
|
|
|
|
| |
RELNOTES:
Iterating on a `depset` object is deprecated. If you need an iterable,
call the `.to_list()` method first.
PiperOrigin-RevId: 159672887
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is part of cleaning up the ActionInputFileCache / MetadataHandler split.
Both classes generally store and return identical information, except the
MetadataHandler lies about constant metadata artifacts. Instead of lying here,
update the ActionCacheChecker, which is the only place where we actually want
constant metadata.
Additionally, remove getMetadataMaybe; again, the only caller that needs
special casing is the ActionCacheChecker, so we move the special casing there
instead of having it in the MetadataHandler.
PiperOrigin-RevId: 159665345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This essentially works by activating the annotation processor
over such rules, even though technically that's unnecessary (since
there are no new resources to process). But running the annotation
processor guarantees we still process deps' resources, which
guarantees the Java compiler references any Java classes
mentioned in those resources.
This prevents JavaBuilder's ---reduce_classpath from pruning these
files out of the compilation classpath because "they were never used".
PiperOrigin-RevId: 159597671
|
|
|
|
|
|
| |
Part of #2219.
PiperOrigin-RevId: 159596011
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
See bazelbuild/bazel#3172
*** Original change description ***
Add an experimental flag to Turbine to indicate to annotation processors that they are running in hjar compilation
PiperOrigin-RevId: 159585343
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 159580867
|
|
|
|
|
|
|
|
|
| |
Also remove warning about macOS bug in 0.5.0 and instructions about JDK7
Fixes https://github.com/bazelbuild/bazel/issues/3222
RELNOTES: None
PiperOrigin-RevId: 159569520
|
|
|
|
|
|
|
|
| |
Tool.AR is used by go rules, and the inconsistency fixed in this cl was causing a bug.
Fixes #3184.
RELNOTES: None.
PiperOrigin-RevId: 159562216
|
|
|
|
|
|
| |
Cuts down on file count and makes it easier to find these methods.
PiperOrigin-RevId: 159560422
|
|
|
|
|
|
| |
constructor.
PiperOrigin-RevId: 159557168
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 159553343
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 159551331
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is_not_cc_test_link_action
If only hlopko@ used brain when he introduced is_not_cc_test_link_action he
would realize that the current values make it impossible to migrate away from
them. This cl introduces new build variable with boolean value. Then I can
update internal crosstools to use expand_if_true/false, and then I can remove
is_not_cc_test_link_action.
RELNOTES: None.
PiperOrigin-RevId: 159549814
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Original change description ***
Access interface constants to explicitly trigger the execution of interface
initializers. The problem is that when we desugar default methods, the static
intializer of interface will not be executed. The JVM spec says that if an
interface has default methods, then when it is loaded, it will also be
initialized. After we desugar such an interface, its default methods are
removed, and when we load the interface, the <clinit> will not be executed.
This CL checks whether an interface has default me...
***
ROLLBACK_OF=159496992
NO_SQ=PURE_ROLLBACK
RELNOTES: None
PiperOrigin-RevId: 159545752
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 159537816
|
|
|
|
| |
PiperOrigin-RevId: 159498323
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
initializers. The problem is that when we desugar default methods, the static
intializer of interface will not be executed. The JVM spec says that if an
interface has default methods, then when it is loaded, it will also be
initialized. After we desugar such an interface, its default methods are
removed, and when we load the interface, the <clinit> will not be executed.
This CL checks whether an interface has default methods and fields. If yes (needs to be initialized when the interface is loaded), it injects field access code
to access the interface fields in the <clinit> of the companion class.
We also create a constant $$CONSTANT$$ in the companion class.
Then for all the classes that implement the interface, we inject GETSTATIC in the class <clinit> to the $$CONSTANT$$ of the companion class of the interface. This indirection is to avoid the IllegalAccessError when the interface is package private.
Note that accessing an arbitrary interface field does not guarantee the
interface will be initialized. We need to access the field that is initialized
in the interface static initializer.
RELNOTES: None
PiperOrigin-RevId: 159496992
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 159496805
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/4929ad79865f8c13ef3b33c827040f4a037e4afe
And use params files for turbine actions with transitive classpaths
For actions where direct deps cannot be used, turbine spawns should always use
params files. The transitive classpath may exceed the command line length
limit.
PiperOrigin-RevId: 159473987
|
|
|
|
|
|
|
|
|
| |
the currently defined hash function for blobs. Some refactoring. Adding an option to set the hash function in the remote worker, defaulting to the current behavior (unfortunately it is a build option, have not found a clean way to specify it at runtime).
BUG=62622420
TESTED=remote worker
RELNOTES: none
PiperOrigin-RevId: 159473116
|
|
|
|
|
|
|
|
|
|
|
|
| |
friends.
The wrapping provider contains its own provider map containing any providers that may conflict. This can be used generally for any aspect that wants to override its base providers (during migration), and due to the generality we should be able to cut down on code size and complexity.
Once we have this, we can more easily and uniformly bind aspects to Skylark for aspect-on-aspect functionality. The Skylark providers can be instantiated with a wrapping provider if one is present, or fall through to the base target if they aren't.
We will also likely save a bit of memory from cutting down on wrapping classes.
PiperOrigin-RevId: 159461325
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 159460633
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 159438707
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 159438506
|
|
|
|
| |
PiperOrigin-RevId: 159438112
|
|
|
|
| |
PiperOrigin-RevId: 159437945
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 159436969
|
|
|
|
|
|
|
|
|
|
| |
I want to make the color scheme configurable, which requires an abstraction
to represent color, so it can be looked up / stored in a map / etc.
Closes #2487.
Change-Id: I2f8bd0dd19ecd6a243ac9b7acc7be52e59c90021
PiperOrigin-RevId: 159426774
|
|
|
|
| |
PiperOrigin-RevId: 159423459
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not using a --incompatible-change flag because it's not available in the
parser. We could pass it, but I think this is trivial to fix and unlikely to
happen in real code (if it does, there was most likely a bug).
RELNOTES[INC]:
Operators for equality, comparison, 'in' and 'not in' are no longer associative,
e.g. x < y < z is now a syntax error. Before, it was parsed as: (x < y) < z.
PiperOrigin-RevId: 159422042
|
|
|
|
|
|
|
| |
Move everything to ActionExecutionContext, and drop Executor whereever possible.
This clarifies the API, makes it simpler to test, and simplifies the code.
PiperOrigin-RevId: 159414816
|
|
|
|
|
|
|
| |
errors are used in some of the test cases.
RELNOTES: None
PiperOrigin-RevId: 159275483
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 159263527
|
|
|
|
|
|
|
| |
Fixed https://github.com/bazelbuild/bazel/issues/3043
Change-Id: Ibbe6ba945bbd439cd84676fcb7fd7ecbbb99e5f0
PiperOrigin-RevId: 159261292
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks dozens of targets in the nightly with Tool Failure errors
*** Original change description ***
Clean up turbine action creation
Support disabling javac fallback for actions without a direct
classpath, and only use the 'JavacTurbine' mnemonic for spawns
that require javac-turbine due to annotation processing to make
it easier to collect metrics on that.
Finally, remove --java_header_compilation_direct_classpath now
that it has been productionized and enabled by default.
PiperOrigin-RevId: 159260596
|
|
|
|
|
|
| |
RELNOTES[INC]: The --output=location flag to 'bazel query' cannot be used with query expressions that involve the 'buildfiles' or 'loadfiles' operators. This also applies to 'genquery' rules.
PiperOrigin-RevId: 159259061
|
|
|
|
|
|
|
|
|
| |
This inner class has no reason to be non-static that I can see.
This should have no effect on memory if I understand how Java
memory usage works, but it confused me, so I cleaned it up.
RELNOTES: None.
PiperOrigin-RevId: 159255460
|
|
|
|
|
|
|
|
|
|
|
| |
Not all bazel invocations produce a BuildStartingEvent; in fact, not all
commands include building. Those invocations produce a NoBuildEvent instead.
However, some of those invocations, like "query", might still have important
machine-readable information to report, like errors in BUILD files. So, make
the NoBuildEvent a build event, capable of starting a stream of build events.
Change-Id: I7cab65f029cdc0176ea5c4970308de296fb73177
PiperOrigin-RevId: 159230205
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 159228238
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code previously threw StringIndexOutOfBoundsException if the client
env contained just a variable name with no '=' or value.
Fixed #3196.
Change-Id: I5afcaa398ab2e8bacc709445f50ba363659cadbb
Closes #3197.
Change-Id: I5afcaa398ab2e8bacc709445f50ba363659cadbb
PiperOrigin-RevId: 159222809
|
|
|
|
|
|
|
|
|
| |
that are potentially timeout flaky and getSuggestedTestTimeout is less likely to suggest timeouts that can result in timeout flakiness.
Also modernized and refactored TestTimeout to be more understandable.
RELNOTES: Adjust the thresholds for --test_verbose_timeout_warnings so that it can recommending timeout increases and won't recommend timeouts that are too close to the actual timeout.
PiperOrigin-RevId: 159222380
|
|
|
|
| |
PiperOrigin-RevId: 159221067
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change, resource filtering by densities could rearrange the
ordering of resources. However, resource merging behavior is dependant on
resource ordering, so changing the order could lead to changed merge results.
Instead, ensure that the filtered resources appear in the same order as they
did in the original list of resources.
RELNOTES: none
PiperOrigin-RevId: 159219647
|