| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
| |
Update the runfiles test's mock Python binary to
run another mock Python binary and assert that the
outer binary propagates the runfiles information
to the inner one.
See https://github.com/bazelbuild/bazel/issues/4460
Change-Id: I3bba799a376642196777f7bc988837084a53bc93
PiperOrigin-RevId: 184650962
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 184649483
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 184619885
|
|
|
|
| |
PiperOrigin-RevId: 184587712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
native skyframe implementation was actually quite incorrect in this case: It was adding a skyframe dependency on a FileValue for the output file. Without a transitive dependency on the source files and actions that determine the output file's state, this could never work (and explains why the incremental build would fail). Instead, we now depend on the Artifact corresponding to the output file instead.
This change updates the business logic RecursiveFilesystemTraversalFunction. This approach keeps the business logic of Fileset filesystem traversal centralized in RFTF.
To avoid making weird recursive Skyframe nodes in the output tree, we inline Skyframe dependencies and do direct filesystem operations over the output tree.
There are now three states we can be in when looking up a file:
1. Source file: As before, make a skyframe dep on the corresponding file
2. Top-level file of an output tree: Make a dep on the corresponding Artifact
3. Recursive file under an output directory: Do direct filesystem operations. It doesn't make sense to make Skyframe nodes corresponding to these files. In the future, I think we should consider failing fast on this case.
RELNOTES: None
PiperOrigin-RevId: 184556044
|
|
|
|
|
|
|
|
| |
essentially promote OwnedArtifact to ArtifactSkyKey and rename it to ArtifactSkyKey. The king is dead...
Also add some other execution-phase codecs.
PiperOrigin-RevId: 184552706
|
|
|
|
| |
PiperOrigin-RevId: 184540561
|
|
|
|
|
|
| |
SpecialArtifact.
PiperOrigin-RevId: 184539696
|
|
|
|
|
|
|
|
| |
We're now using ctime to detect file changes, so the timestamp granularity monitor should as well.
Unfortunately, we currently get nanosecond ctime from Linux, but then only return millis from FileStatus, so this doesn't change the accuracy of the monitor at all.
PiperOrigin-RevId: 184536539
|
|
|
|
|
|
|
| |
Fix the create_main_dex_list stub script to find the dx jar binary correctly.
RELNOTES: None
PiperOrigin-RevId: 184532530
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
child of the process where the Blaze client itself was run.
Limitations:
- Untested on Windows; it should work because ExecuteProgram() is implemented there, too, but since Windows doesn't support exec(), there is at least one process in between
Progress towards #2815.
RELNOTES[NEW]: The new "--direct_run" flag on "blaze run" lets one run interactive binaries.
PiperOrigin-RevId: 184528845
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also update the Python stub script template to set
$RUNFILES_MANIFEST_FILE or $RUNFILES_DIR so the
runfiles library only needs to look for those.
See https://github.com/bazelbuild/bazel/issues/4460
RELNOTES[NEW]: python,runfiles: You can now depend on `@bazel_tools//tools/runfiles:py-runfiles` to get a platform-independent runfiles library for Python. See DocString of https://github.com/bazelbuild/bazel/blob/master/src/tools/runfiles/runfiles.py for usage information.
Change-Id: I4f68a11cb59f2782e5203e39fe60cc66b46023a2
PiperOrigin-RevId: 184515490
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 184498836
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 184492828
|
|
|
|
|
|
|
| |
Fixes #4563.
Change-Id: I12868569feb1ec700062006307cda15c24946797
PiperOrigin-RevId: 184490058
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 184411715
|
|
|
|
|
|
|
|
| |
either a Label or a List<Label>. We can easily enforce this through static type checking, so do it.
This will help with LateBoundDefault serialization, since we don't have to serialize an arbitrary object.
PiperOrigin-RevId: 184347100
|
|
|
|
|
|
| |
declaration.
PiperOrigin-RevId: 184304653
|
|
|
|
|
|
|
|
|
| |
This test currently times out when run on our CI and we don't have a root
cause yet -- but it's blocking all submissions. Thus disable it in the
meantime while we investigate.
RELNOTES: None.
PiperOrigin-RevId: 184304422
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Did not help so there is no need to carry this further.
*** Original change description ***
tests: increase shard_count for launcher_test
This test is timing out on internal CI, breaking
presubmits.
RELNOTES: none
PiperOrigin-RevId: 184283585
|
|
|
|
|
|
|
|
|
| |
Bazel completely swallowed errors in some cases, e.g., if the pattern is
invalid like bazel build foo//bar:baz.
Note that it previously silently ignored empty targets if --experimental_skyframe_target_pattern_evaluator was passed, and now fails (which is consistent with legacy behavior). This is an intentional change, but may break users who are using the experimental flag and are passing empty strings to Bazel.
PiperOrigin-RevId: 184282856
|
|
|
|
|
|
|
| |
In scope of b/69780248 three new provider had been added to JavaInfo. This CL implements merge logic for its.
RELNOTES:none
PiperOrigin-RevId: 184273903
|
|
|
|
|
|
|
|
| |
This test is timing out on internal CI, breaking
presubmits.
RELNOTES: none
PiperOrigin-RevId: 184270477
|
|
|
|
|
|
|
|
|
| |
This makes object_file_group work correctly for archiving (So far
object_file_group was only possible for linking, but with the introduction of
tree artifact support, it can appear also for archiving).
RELNOTES: Fix how libraries_to_link are expanded in the archiver command line.
PiperOrigin-RevId: 184258745
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove most of the hardcoded, Windows-only envvars
from testenv.sh:
- BAZEL_VC and BAZEL_PYTHON: Bazel can autodetect
these
- TMP/TEMP/TMPDIR and TEST_TMPDIR: Bazel sets
these automatically
As for BAZEL_SH, we can just get bash's path using
cygpath. We know there is a bash since this is
already inside a bash script.
Also, use `rlocation` for some of the the runfile
lookups.
Change-Id: Ib35d285ec0cbb88cb5d603a4eb0f3386f3c2033b
PiperOrigin-RevId: 184253597
|
| |
|
|
|
|
|
|
|
| |
android_instrumentation_test_integration_test
RELNOTES: None.
PiperOrigin-RevId: 184203486
|
|
|
|
|
| |
RELNOTES:
PiperOrigin-RevId: 184191201
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check the no_proxy and NO_PROXY environment variables for a list of URLs that
should not use a proxy. If the requested URL matches the no_proxy list, don't
proxy the download.
Fixes #4299
Closes #4307.
PiperOrigin-RevId: 184149118
|
|
|
|
|
|
|
|
| |
This makes way more sense than using the name of the *parent* directory of the workspace.
Closes #4253 - thanks @akira-baruah for suggesting this change and making it happen!
PiperOrigin-RevId: 184147456
|
|
|
|
| |
PiperOrigin-RevId: 184144301
|
|
|
|
|
|
| |
CppCompileAction serialization.
PiperOrigin-RevId: 184141676
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks //third_party/msvc crosstool
*** Original change description ***
RELNOTES: Fix how libraries to link is specified to archiver actions.
start-lib/end-lib should not be passed to ar. Fix how the libraries to link are passed to ar by not using the generic feature "libraries_to_link"
PiperOrigin-RevId: 184140734
|
|
|
|
|
|
| |
This is needed to migrate JavaCompileAction away from CustomMultiArgv.
PiperOrigin-RevId: 184136486
|
|
|
|
|
|
|
|
|
| |
..by the `build_file` parameter, even if the external repository contains a
top-level BUILD file. While there, also add a test verifying that this is
also possible via the `build_file_content`.
Change-Id: I1b875c147cfcd6f1c70b8efeb10c2b406eeacf6a
PiperOrigin-RevId: 184134041
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks on our CI Linux machines (but works on our work desktop Linux machines); apparently, even our own Linux machines are too different from each other...
Fixes #4557
*** Original change description ***
http_archive: verify that unicode characters are OK in tar archives
Add a test verifying that http_archive can extract a tar archive
containing unicode characters. While such files cannot be referred
to by labels, it is still important that the archive can be extracted.
Also fix that use case on Darwin, by appropriately reencoding the string,
so that the Files java standard library can encode it back to what we
had in the first place.
Work-around for #1653, showing that http_archive from @bazel_tools can
be used; however, the issue still remains for zip archives.
***
PiperOrigin-RevId: 184132385
|
|
|
|
|
|
|
| |
android_instrumentation_test.test_app
RELNOTES: None
PiperOrigin-RevId: 184063294
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the same mapFn class.
This code tries to add protection against the user creating new mapFn instances per-rule. This would cause the nested set cache to be computed per-rule instead of shared across rule instances, causing memory bloat and slowdowns.
Since this can only happen in native code, we can get away with detecting this and crashing blaze. I think this is a better choice than silently allowing it / falling back to slow computations.
The user can override this behaviour by inheriting from CommandLineItem.CapturingMapFn, in which case the user is explicitly saying they assume responsibility for the number of instances of the mapFn the application will use.
PiperOrigin-RevId: 184061642
|
|
|
|
|
|
|
| |
ConfiguredTargetAndTarget instead of a ConfiguredTarget.
This is to assist in deprecating ConfiguredTarget.getTarget().
PiperOrigin-RevId: 184043491
|
|
|
|
|
|
|
| |
This allows writing Android testing rules that consume DeviceBrokerInfo.
RELNOTES: None
PiperOrigin-RevId: 184026202
|
|
|
|
|
|
|
|
|
| |
Instead of using ConcurrentHashMap, we use a dead-simple open addressed hash hable with a giant byte array with 16-byte slots. We then read or write fingerprints straight into and out of the array, obviating the need to generate intermediate garbage.
Locking mechanism is a read-write lock. This should be faster than full synchronisation for read-heavy loads.
RELNOTES: None
PiperOrigin-RevId: 184019301
|
|
|
|
|
|
|
| |
Fixes #3735.
RELNOTES: java_common.compile supports neverlink
PiperOrigin-RevId: 184017410
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 184016150
|
|
|
|
| |
PiperOrigin-RevId: 183990860
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a test verifying that http_archive can extract a tar archive
containing unicode characters. While such files cannot be referred
to by labels, it is still important that the archive can be extracted.
Also fix that use case on Darwin, by appropriately reencoding the string,
so that the Files java standard library can encode it back to what we
had in the first place.
Work-around for #1653, showing that http_archive from @bazel_tools can
be used; however, the issue still remains for zip archives.
Change-Id: If944203bf618c21705af676347d8591ab015d559
PiperOrigin-RevId: 183987726
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 183978326
|
|
|
|
|
|
| |
CppCompileAction smaller improves serialization.
PiperOrigin-RevId: 183871454
|
|
|
|
| |
PiperOrigin-RevId: 183859414
|
|
|
|
|
|
|
|
|
| |
It is not compatible with multiple execution platforms.
Part of #4442.
Change-Id: I683beaae1624130352a6f02bae3f4dfff263ea00
PiperOrigin-RevId: 183855561
|
|
|
|
|
|
|
| |
Part of #4442.
Change-Id: Ia9c4403817d9c1e6497212712f96dbf6618138e9
PiperOrigin-RevId: 183855255
|