| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
Blaze had its own class to avoid GC from varargs array creation for the precondition happy path. Guava now (mostly) implements these, making it unnecessary to maintain our own.
This change was almost entirely automated by search-and-replace. A few BUILD files needed fixing up since I removed an export of preconditions from lib:util, which was all done by add_deps. There was one incorrect usage of Preconditions that was caught by error prone (which checks Guava's version of Preconditions) that I had to change manually.
PiperOrigin-RevId: 175033526
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 175033155
|
|
|
|
|
|
|
| |
Fix #2760.
Change-Id: Iab98fad1ca025c4af7a7048bb7048947ef90d61d
PiperOrigin-RevId: 175030992
|
|
|
|
|
|
|
|
|
| |
unlike earlier versions,
openjdk9 returns "javac 9" when asked for its version
Closes #4004.
PiperOrigin-RevId: 175029317
|
|
|
|
| |
PiperOrigin-RevId: 175027144
|
|
|
|
|
|
| |
RELNOTES: None.
Change-Id: I9f9295df15edf1f701e9003bca4021f78540c1eb
|
|
|
|
|
|
| |
This change prepares a move to Guava's preconditions. Guava only has vararg-avoiding overloads up to 4 args.
PiperOrigin-RevId: 175015502
|
|
|
|
|
|
|
| |
This is now done by a Google Cloud Container Builder job.
Change-Id: I33a9543f9b5bdb083171482e9eaebdb43e77181b
PiperOrigin-RevId: 174905217
|
|
|
|
|
|
|
|
| |
The previous fix (https://github.com/bazelbuild/bazel/commit/da30589fb9b7f4abe7280ffef73da909c1706b49) was incomplete.
Anchor names were missing for some sections.
RELNOTES: none
PiperOrigin-RevId: 174896528
|
|
|
|
|
|
|
| |
While at it, I added a flag "--single-file" that turns on single file mode. In this mode, only the specified file will be read (there is no dependency analysis).
RELNOTES: none
PiperOrigin-RevId: 174888506
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 174884178
|
|
|
|
|
|
|
| |
Fix #4027.
Change-Id: I609286c21bd6c503196d122205423726d7e42997
PiperOrigin-RevId: 174880389
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 174874118
|
|
|
|
|
|
| |
Now with more accuracy.
PiperOrigin-RevId: 174873635
|
|
|
|
|
|
|
|
|
|
| |
BES.
- Add a prefix to user provided keywords, so it can be distinguished from
keywords provided directly by Bazel.
- Keywords are also stored in a Set to avoid duplicates.
PiperOrigin-RevId: 174872442
|
|
|
|
|
|
| |
Fixes #2355.
PiperOrigin-RevId: 174871644
|
|
|
|
|
|
| |
This target was removed.
PiperOrigin-RevId: 174870373
|
|
|
|
| |
PiperOrigin-RevId: 174867981
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 174866874
|
|
|
|
| |
PiperOrigin-RevId: 174818556
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 174803631
|
|
|
|
|
|
|
|
| |
This is both probably what the user most cares about, and also restores a Skyframe invariant, that as a catastrophic exception bubbles up, it stays catastrophic.
There is actually no hard Skyframe requirement for that, so we could consider relaxing it, but I'm willing to keep it for now.
PiperOrigin-RevId: 174759976
|
|
|
|
|
|
| |
//tools/cpp:toolchain_type as the canonical c++ toolchain.
PiperOrigin-RevId: 174759558
|
|
|
|
|
|
|
|
|
|
|
| |
Characterizing this correctly this time: Target patterns are evaluated with two different sets of semantics. For determining which targets to build, only test suites in exclusion target patterns are expanded. For determining which tests to run (or determining which targets to build if --build_tests_only is set), test suites in all target patterns are expanded. In each case, test suites are expanded for each target pattern individually, not for the whole set of targets after the list of target patterns is processed.
Also update a related code comment.
The newer implementation for this logic already has equivalent tests for this behavior, in particular testFilterNegativeTestFromTestSuite and testNegativeTestSuiteExpanded in LoadingPhaseRunnerTest.
RELNOTES: None
PiperOrigin-RevId: 174756583
|
|
|
|
|
|
|
|
|
|
| |
value of --max_idle_secs is 15s when the TEST_TMPDIR environment variable is set.
(i) Add a log line to blaze.INFO when the server shuts itself down due to idleness.
(ii) Mention the --max_idle_secs default in the existing stderr spam when TEST_TMPDIR is set.
RELNOTES: None
PiperOrigin-RevId: 174745511
|
|
|
|
|
|
|
|
| |
These libs are exposed externally, implying that the vfs is also exposed externally.
We break out PathFragment from vfs to still use this in their interface. This class is a much smaller dependency than the entire vfs.
PiperOrigin-RevId: 174729373
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 174719828
|
|
|
|
|
|
|
| |
RELNOTES: AAR manifest files will come from the processed resource APK if it
exists.
RELNOTES: None for Blaze users.
PiperOrigin-RevId: 174622961
|
|
|
|
|
|
|
| |
TerminationStatus, and also add a TerminationStatus.Builder and tests.
RELNOTES: None.
PiperOrigin-RevId: 174557303
|
|
|
|
|
|
|
| |
and make cumulative execution times available in ActionResults.
RELNOTES: None
PiperOrigin-RevId: 174553272
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
This doesn't seem to be correct. I was confused by an example where a target is excluded from being run, but still built.
*** Original change description ***
RELNOTES: Document interaction between test_suite and target exclusions
PiperOrigin-RevId: 174536378
|
|
|
|
|
| |
RELNOTES: Late-bound attributes are exposed to skylark. This is a new API (`configuration_field()`) to depend on certain configuration-defined targets from skylark rules.
PiperOrigin-RevId: 174534104
|
|
|
|
|
|
|
| |
This changes the order in which expansions happen, which could change the
semantics in subtle ways.
PiperOrigin-RevId: 174518778
|
|
|
|
|
|
| |
into separate topics.
PiperOrigin-RevId: 174510719
|
|
|
|
| |
PiperOrigin-RevId: 174508154
|
|
|
|
|
|
| |
#getObjCopyOptionsForEmbedding, #getLdOptionsForEmbedding and #getDefaultSysroot to CcToolchainProvider.
PiperOrigin-RevId: 174508128
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 174503874
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 174502289
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Building a binary rule does not generally ensure that the runfiles
trees of its transitive data dependencies are up-to-date, so it's
generally a bad idea to use a dependency's runfiles tree from the
primary target. See https://github.com/bazelbuild/bazel/issues/3919
for an example of the problems this can cause.
This CL ensures that we pick the primary target's runfiles tree when
executing a java_binary from a runfiles tree.
This makes the Java runfiles path resolution similar to that of the
Python rules. (See commit [1].)
[1] 58ee85afcab07374dabc5493c780cbe3369b644f ("Don't follow symlink when looking for python module space")
Change-Id: I412ede5cf02ab2c407e45a2b262442ca67df9ba6
PiperOrigin-RevId: 174501597
|
|
|
|
|
|
|
| |
Follow up to https://github.com/bazelbuild/bazel/commit/c50cd13c75a2a1685f5ac9bd70561ac1e50722e7
RELNOTES: None.
PiperOrigin-RevId: 174498205
|
|
|
|
|
|
| |
CcToolchainProvider#getFeatures.
PiperOrigin-RevId: 174492427
|
|
|
|
|
|
|
|
| |
I used [GNU Aspell](http://aspell.net/) to quickly look through markdown files in `site/docs/` for typos. Still involved a bit of manual checking, but ultimately found a handful of spelling errors.
Closes #3944.
PiperOrigin-RevId: 174490875
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no need to defer the action creation and scheduling, which
happens shortly thereafter, and just requires saving a bunch of information
on the LtoBackendArtifact.
This is preliminary restructuring that will aid some larger changes for
making tests that use static linking more efficient when built with ThinLTO
(for b/67424063).
RELNOTES: None
PiperOrigin-RevId: 174490283
|
|
|
|
|
|
|
|
|
|
| |
Clarify that bash_completion script is already installed when installing bazel from the custom APT repository.
https://github.com/bazelbuild/bazel/issues/1539
Closes #3904.
PiperOrigin-RevId: 174489508
|
|
|
|
|
|
|
| |
subclassed by a skylark-specific implementation
RELNOTES: None.
PiperOrigin-RevId: 174486116
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 174485947
|
|
|
|
| |
PiperOrigin-RevId: 174482602
|
|
|
|
| |
PiperOrigin-RevId: 174481563
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 174479316
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whether a resource is accepted or rejected by density-based resource filtering
is dependent on what other resources are available. When filtering resources in
execution, this was taken into account - resources were filtered after merging.
To replicate this behavior when filtering in analysis, we must look at both
local and transitive resources before we actually filter anything.
This process makes filtering with dynamic configuration extremely inefficient, since the NestedSet of transitive resources must be collapsed at each library target. We can fix this by only looking at the transitive resources at the top-level target, even when using dynamic filtering. I'm not implementing that in this change, however, since dynamic filtering is relatively low priority and this review is already pretty big.
Note that some of the messiness around filtering ResourceDependencies and
NestedSet<ResourceContainer> will go away once those NestedSets are removed.
Also, stop filtering resources in android_test, since android_test can never specify resource filters.
RELNOTES: none
PiperOrigin-RevId: 174474491
|