| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
This is in preparation for deleting CcLinkParamsStore. Not all calls to
setCcLinkparamsStore have been removed in this CL.
Roll forward with bzl change in separate CL (unknown commit) and giving a proper error in Skylark instead of a crash when CcLinkingInfo is not built correctly.
RELNOTES:none
PiperOrigin-RevId: 206122870
|
|
|
|
| |
PiperOrigin-RevId: 206102499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
struct.to_json.
Dictionaries are frequently used for generic configuration descriptions especially
given that `struct` is not allowed in build files.
In order to be JSON-compatible, only dictionaries with string keys are allowed.
Technically Python also allows integers and booleans by automatically converting
them to strings, but this is confusing and not necessarily a good thing to do.
Fixes #5542
Closes #5543.
PiperOrigin-RevId: 206049754
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an option to provide a file with a resolved value, that will be
used to verify that the repositories mentioned in this file produce
a correct directory tree.
RELNOTES: newly added options --experimental_repository_hash_file and
--experimental_verify_repository_rules allow to verify for repositories
the directory generated against pre-recorded hashes. See documentation
for those options.
Work towards #5660.
Change-Id: I2d8becb188d0fa51e890fb8f6139f321cca14b7b
PiperOrigin-RevId: 206016792
|
|
|
|
|
|
|
|
|
|
| |
to avoid confusion between the LHS and RHS host_javabases.
The LHS --host_javabase option should be considered deprecated and will
eventually be removed.
RELNOTES: Rename the startup flag --host_javabase to --server_javabase to avoid confusion with the build flag --host_javabase
PiperOrigin-RevId: 206015757
|
|
|
|
|
|
|
| |
This avoids bazel crashes for illegally formatted strings. Previously the code would assume that a correct string was passed with only minimal validation.
RELNOTES: None
PiperOrigin-RevId: 206012819
|
|
|
|
|
|
| |
Closes #5626.
PiperOrigin-RevId: 205991094
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, refactor the code to use TargetPatternPhaseValue exclusively. This
removes the need to convert from TargetPatternPhaseValue to LoadingResult, and
prepares for interleaving.
It also reduces the number of Skyframe calls which may speed up null builds a
bit, as a followup for https://github.com/bazelbuild/bazel/commit/1067310e18cb9ac203110726de0be53bdc403cea.
PiperOrigin-RevId: 205989338
|
|
|
|
|
|
|
|
|
|
| |
The only remaining use was a testing REST backend in the LRE.
I wrote a replacement for that using netty, which we use for our network stuff in Bazel, which means we can now get rid of Hazelcast. :)
I'll remove the Hazelcast files in a separate change when this is merged.
PiperOrigin-RevId: 205985996
|
|
|
|
|
|
|
| |
aren't used anymore.
RELNOTES: None.
PiperOrigin-RevId: 205984908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For downloading output files / directories we trigger all
downloads concurrently and asynchronously in the background
and after that wait for all downloads to finish. However, if
a download failed we did not wait for the remaining downloads
to finish but immediately started deleting partial downloads
and continued with local execution of the action.
That leads to two interesting bugs:
* The cleanup procedure races with the downloads that are still
in progress. As it tries to delete files and directories, new
files and directories are created and that will often
lead to "Directory not empty" errors as seen in #5047.
* The clean up procedure does not detect the race, succeeds and
subsequent local execution fails because not all files have
been deleted.
The solution is to always wait for all downloads to complete
before entering the cleanup routine. Ideally we would also
cancel all outstanding downloads, however, that's not as
straightfoward as it seems. That is, the j.u.c.Future API does
not provide a way to cancel a computation and also wait for
that computation actually having determinated. So we'd need
to introduce a separate mechanism to cancel downloads.
RELNOTES: None
PiperOrigin-RevId: 205980446
|
|
|
|
|
|
|
|
| |
This makes the tests run much faster.
Fixes #5443
RELNOTES: None.
PiperOrigin-RevId: 205980410
|
|
|
|
| |
PiperOrigin-RevId: 205876673
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Fixed duplicate derived inputs bug. Test is in diffbase.
RELNOTES[INC]: If the same artifact is generated by two distinct but identical actions, and a downstream action has both those actions' outputs in its inputs, the artifact will now appear twice in the downstream action's inputs. If this causes problems in Skylark actions, you can use the uniquify=True argument in Args.add_args.
PiperOrigin-RevId: 205863806
|
|
|
|
|
|
|
|
| |
RELNOTES: java_common.compile creates the native headers jar accesible via JavaInfo.outputs.native_headers.
Closes #5662.
PiperOrigin-RevId: 205832180
|
|
|
|
|
|
|
|
|
|
|
| |
Also simplify LoadingPhaseCompleteEvent, and SkyframeExecutor, and remove
LoadingCallback, which is unnecessary now that we only have a single
implementation (previously LoadingPhaseRunner).
This also removes some of the excessive Skyframe calls introduced by
https://github.com/bazelbuild/bazel/commit/1067310e18cb9ac203110726de0be53bdc403cea, and prepares for interleaving target pattern eval and loading.
PiperOrigin-RevId: 205813197
|
|
|
|
|
|
|
| |
Each FileSystem instance has a digest function, but the getDigest and getHashDigest functions also accepted their own custom parameter functions. We only support 1 hash per filesystem instance, these parameters are redundant.
RELNOTES: None.
PiperOrigin-RevId: 205758571
|
|
|
|
|
|
|
| |
in a very specific window of time inbetween enqueueing one top-level node for evaluation and checking if another top-level node is done. See the added unit test for details.
RELNOTES: None
PiperOrigin-RevId: 205718683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On two fronts: First, it should follow standard command line semantics. Second, it should work as intended: --noblock_for_lock means the client will not wait for another command to finish, but will exit eagerly. It can be useful for preventing hanging in applications that are non-interactively calling bazel.
It should have standard startup-option semantics: the default value is accepted as a no-op or can be provided to override a previous value.
The next issue involves 2 different locks - the client lock, and the server-side command lock. This duality exists because we would like, one day, to be able to run certain commands, like info or help, at the same time, so multiple commands would need specialized locks that allow some duality but blocks others. This can only be done at the server level, so as soon as the client gets the "we're connected" grpc message from the server, it releases the client lock and lets the server manage multiple requests.
There are basically 3 possible states that are relevant to this option:
1) no other client is active, so no one holds the client lock or the command lock - the server can be used, shutdown or started as needed. - no blocking, but no need to block, either, so we're safe
2) another client (client1) holds the lock, but it is currently using a server that we want to reuse. If client1 still holds the client lock, we fail fast. Same thing if client1 is holding the server-side lock: we will exit gracefully when the BlazeCommandDispatcher responds with a failure.
3) client1 holds the lock but its server cannot be reused. (batch clients also fall into this category, as there is no server to reuse - but in this case, the client lock is still in play). However, for server mode, this is broken - the following happens:
- Server is occupied with client1's request, holds the command lock
- client2 wants to restart the server, so sends the old server a "shutdown" command
- the BlazeCommandDispatcher says - nuh-uh, this is busy, and you said you didn't want to wait for the lock
- client2 absorbs this response
- waits (blocks...)
- for a minute
- then force shuts-down the old server.
So we had 2 problems - we block, and we shutdown a server that we truly intended to keep going. Now, if the server responds saying another action is using it, the client will exit correctly, and leave the old server to do its thing.
RELNOTES: None.
PiperOrigin-RevId: 205671817
|
|
|
|
|
|
|
|
|
| |
Fixes #5331.
Change-Id: Idb01a3f206ed37992f200f7e0e51ed9831262613
RELNOTES: Code coverage is collected for Java binaries invoked from sh_test.
PiperOrigin-RevId: 205654442
|
|
|
|
|
|
|
|
|
| |
disabling relying on CROSSTOOL file in order to select the cc_toolchain label
CROSSTOOL file should not have any influence over selection of the cc_toolchain label. Ultimately the information that CROSSTOOL offers will be rerouted through an attribute of cc_toolchain.
RELNOTES: None.
PiperOrigin-RevId: 205651369
|
|
|
|
|
|
|
|
| |
Default value is true, and behavior related to //tools/defaults package is not
changed. If set it to false, then in-memory Dfaultpacked will not be created.
RELNOTES:none
PiperOrigin-RevId: 205643628
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 205635805
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With invalid contents in the repository cache, silence the IOException
on RepositoryCache::get and re-download an artifact when attempting to
short-circuit that operation. The repository cache can easily get into
this state when a build is interrupted while downloading into the non-
atomic repository cache destination.
Possible solution to #5390
Closes #5392.
PiperOrigin-RevId: 205634761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When reporting about the repository rules that were called, also report
a hash of the tree the rule generated. This allows, at least after the fact,
to verify that a repository rule actually produced the correct code.
Note that equality of the output hash is not a guarantee for reproducible
builds, as certain properties of the output tree, in particular owner,
are ignored. Still it is a good check to detect wrong use of a repository
rule.
Change-Id: Ic56509f8e0d0b4be9ce3335ade280f983fe77e6d
PiperOrigin-RevId: 205631855
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, make ActionMetadataHandler implement the MetadataProvider interface.
This fixes an issue where an action that runs two spawns where one depends on
an output of the other was unable to get the metadata for the intermediate
output.
We don't currently have actions that do this, but we will have in a future
change (which will also implicitly act as a regression test).
PiperOrigin-RevId: 205629237
|
|
|
|
|
|
|
|
| |
It was missing the baseline coverage files, if any.
This is safe even if unknown commit is rolled back.
PiperOrigin-RevId: 205626149
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Update the Flutter rules AndroidSdkInfo provider to FlutterAndroidSdkInfo. AndroidSdkInfo should be unique in the repo now.
*** Original change description ***
Automated rollback of commit 4d10250291a813302de64151be3b22d57e94749d.
*** Reason for rollback ***
AndroidSdkInfo is already being used by the Flutter rules.
*** Original change description ***
Expose AndroidSdkProvider to Skylark (as AndroidSdkInfo).
RELNOTES: None.
PiperOrigin-RevId: 205431461
|
|
|
|
|
|
|
|
| |
contain a subset of the current :rpc3 dependencies.
This will allow the rpc3 server implementation to depend on real java_proto_libraries without a circular dependency.
PiperOrigin-RevId: 205420268
|
|
|
|
|
|
|
| |
RELNOTES[INC]:Labels in C++ rules' linkopts attribute are not expanded anymore
unless they are wrapped, e.g: $(location //foo:bar)
PiperOrigin-RevId: 205385711
|
| |
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 205288166
|
|
|
|
|
|
|
| |
Working towards #4570.
RELNOTES:none
PiperOrigin-RevId: 205274676
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous behavior was to put flags coming from Bazel option --linkopt into
legacy_link_flags. They should be in user_link_flags instead (together with
flags coming from linkopts rule attribute). This cl introduces
--experimental_linkopts_in_user_link_flags option that flips the behavior.
There is another incompatible change. Previously cc_common.create_link_variables() included flags from --linkopt, with the flag flipped it doesn't anymore. I believe
--linkopt flags shouldn't be there by default because:
* We don't tie the API with the specifics of C++ rules/options, enabling theoretical use with other languages (objc)
* Users are free to use ctx.fragments.cpp to access C++ options and add them explicitly (https://github.com/bazelbuild/bazel/issues/5602)
* New behavior maintains the symmetry with --copt and user_compile_flags
RELNOTES: None.
PiperOrigin-RevId: 205274272
|
|
|
|
| |
PiperOrigin-RevId: 205236169
|
|
|
|
|
|
| |
encountered in a Fileset as a regular file.
PiperOrigin-RevId: 205152271
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
AndroidSdkInfo is already being used by the Flutter rules.
*** Original change description ***
Expose AndroidSdkProvider to Skylark (as AndroidSdkInfo).
RELNOTES: None.
PiperOrigin-RevId: 205142459
|
|
|
|
|
| |
RELNOTES: Fixed compatibility with aar_import when using aapt2. AAPT2 is now supported for Android app builds without resource shrinking. To use it, pass the `--android_aapt=aapt2` flag or define android_binary.aapt_version=aapt2.
PiperOrigin-RevId: 205136160
|
|
|
|
|
| |
RELNOTES: none.
PiperOrigin-RevId: 205100703
|
|
|
|
|
|
|
|
| |
FilesetEntryMap for the aspect's RuleContext.
The current logic in createFilesetEntryMap() uses the rule of the RuleContext.Builder to determine whether to create a filesetEntryMap or not, because of this, applying an aspect to a generated file of a fileset (e.g. 'out' attribute of a Fileset) causes createFilesetEntryMap to create the map even though the associated target is, for instance, a generated file. As a consequence, applying any aspect to a generated file of a fileset causes a NullPointerException.
PiperOrigin-RevId: 205065778
|
|
|
|
|
| |
RELNOTES: Add aquery command to get analysis time information about the action graph.
PiperOrigin-RevId: 205064145
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 205060182
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow the `$TMPDIR` to be empty in
//src/test/shell/bazel:bazel_rules_test.
This used to be the case before commit
https://github.com/bazelbuild/bazel/commit/f814454ff5477418ca44696efb5c71339368efa4
Bazel only guarantees to set TMPDIR for locally
executed tests, but not (to my knowledge) for
remote execution.
Fixes https://github.com/bazelbuild/bazel/issues/5607
Change-Id: I2e97c13d137f94c7f668b7a6c7fc5020a19e4a0b
Closes #5610.
Change-Id: I2e97c13d137f94c7f668b7a6c7fc5020a19e4a0b
PiperOrigin-RevId: 205039105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[Full NDK changelog](https://github.com/android-ndk/ndk/wiki/Changelog-r17)
Changes related to Bazel's NDK toolchain/CROSSTOOL generation:
- Removed support for targeting mips, mips64, armeabi.
- Bumped bundled clang version to 6.0.2.
- The default STL is now libc++. If Bazel detects that r17 is being used, it
aliases `@androidndk//:default_toolchain` to `@androidndk//:toolchain-libcpp`,
instead of `@androidndk//:toolchain-gnu-libstdcpp`.
- Removed tests that build against armeabi, mips, mips64.
- Stop passing `-fno-integrated-as` into the compiler by default.
TODO:
- [x] Java tests
- [x] ~Support for wrap.sh to use with ASANs~ Implementing in follow up PR.
- [ ] Fix or disable remote caching with android_ndk_integration_test https://github.com/bazelbuild/bazel/issues/4663
Fixes https://github.com/bazelbuild/bazel/issues/4742
RELNOTES: Added support for Android NDK r17. The default STL is now `libc++`, and support for targeting `mips`, `mips64` and `ARMv5` (`armeabi`) has been removed.
Closes #5371.
Change-Id: Id1ded004c3a80ea62f307746dc3ad6f633f2df2e
PiperOrigin-RevId: 205013758
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Still bugs lurking. See linked bug.
*** Original change description ***
Automated rollback of commit eb587075b0d6ffab1cf9e69ede1b7e547905e547.
*** Reason for rollback ***
Depot has been fixed.
RELNOTES[INC]: If the same artifact is generated by two distinct but identical actions, and a downstream action has both those actions' outputs in its inputs, the artifact will now appear twice in the downstream action's inputs. If this causes problems in Skylark actions, you can use the uniquify=True argument in Args.add_args.
PiperOrigin-RevId: 204997569
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 204983634
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 204974291
|
|
|
|
|
| |
Change-Id: I13645199a21991b1458264f9d9ac2db2736066b2
PiperOrigin-RevId: 204963740
|
|
|
|
|
| |
Change-Id: I2195a3f7d60e9835bc00d6f151ea91271fdccf6f
PiperOrigin-RevId: 204954233
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cl adds following flags:
* --experimental_disable_legacy_cc_compilation_api
* --experimental_disable_legacy_cc_linking_api
* --experimental_disable_linking_mode_flags
* --experimental_disable_compilation_mode_flags
* --experimental_disable_legacy_crosstool_fields
RELNOTES: None
PiperOrigin-RevId: 204924599
|