| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
When there is a hard limit on the output of the experimental UI, change
the behavior to only write to the underlying stream on flush. In this
way, we can avoid semantically incomplete writes at the moment we
run out of characters.
Change-Id: I024c776ae2139d76d380bb89d13b8fe61d6cfe51
PiperOrigin-RevId: 206000817
|
|
|
|
|
|
|
|
| |
This is in preparation for deleting CcLinkParamsStore. Not all calls to
setCcLinkparamsStore have been removed in this CL.
RELNOTES:none
PiperOrigin-RevId: 205998687
|
|
|
|
|
|
|
| |
detected by FileSystemUtils#readWithKnownFileSize.
RELNOTES: None
PiperOrigin-RevId: 205995852
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 205985818
|
|
|
|
|
|
|
| |
aren't used anymore.
RELNOTES: None.
PiperOrigin-RevId: 205984908
|
|
|
|
|
|
|
|
|
| |
There were convoluted cases with multiple JavaInfo created from Skylark that
didn't have the JavaStrictCompilationArgsProvider. If these were to be merged
and later forwarded with exports we would miss them as dependencies.
RELNOTES: None
PiperOrigin-RevId: 205980933
|
|
|
|
| |
PiperOrigin-RevId: 205980620
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
3 providers had AbstractCcLinkParamsStore as a class field, now they wrap
CcLinkingInfo instead.
This is being rolled forward, first try caused a NullPointerException in
go_wrap_cc rules that had the attribute use_default_import set to False.
GoWrapCcConfiguredTargetTest now has a go_wrap_cc rule that has this attribute
set to false and fails with the previous version of this CL.
RELNOTES:none
PiperOrigin-RevId: 205959266
|
|
|
|
|
|
|
|
|
| |
the declared directories. Especially when doing validation during input
discovery, the discovery's over-approximation can lead to isDeclaredIn walking
the full path to the root without finding a declared include directory.
RELNOTES: None.
PiperOrigin-RevId: 205958078
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Crash with NullPointerException
*** Original change description ***
C++: Remove AbstractCcLinkParamsStore from providers.
3 providers had AbstractCcLinkParamsStore as a class field, now they wrap
CcLinkingInfo instead.
RELNOTES:none
PiperOrigin-RevId: 205885939
|
|
|
|
| |
PiperOrigin-RevId: 205876673
|
|
|
|
|
| |
RELNOTES: The JDK shipped with Bazel was updated to JDK10.
PiperOrigin-RevId: 205865966
|
|
|
|
|
|
|
|
|
|
| |
*** 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: None.
PiperOrigin-RevId: 205850479
|
|
|
|
|
|
|
| |
Comments are misleading, as discussed on https://github.com/bazelbuild/bazel/pull/5305#issuecomment-396288826
RELNOTES: None.
PiperOrigin-RevId: 205841782
|
|
|
|
|
|
|
| |
Fixes #5592.
RELNOTES: Deleting deprecated no-op flag --show_package_location
PiperOrigin-RevId: 205834069
|
|
|
|
|
|
|
|
| |
RELNOTES: java_common.compile creates the native headers jar accesible via JavaInfo.outputs.native_headers.
Closes #5662.
PiperOrigin-RevId: 205832180
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 205825362
|
|
|
|
|
|
|
|
| |
3 providers had AbstractCcLinkParamsStore as a class field, now they wrap
CcLinkingInfo instead.
RELNOTES:none
PiperOrigin-RevId: 205821081
|
|
|
|
|
|
|
| |
This will be used to compute the critical path using Spawns instead of Actions,
which should be more accurate.
PiperOrigin-RevId: 205817400
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
treat java_proto_library.
RELNOTES: None
PiperOrigin-RevId: 205812269
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DeletePath and CreateJunction are now even more
tolerant with errors, particularly the class of
errors where access is denied.
Also in this change:
- remove DeletePathResult::kParentMissing, as this
case is handled by CreateFileW's error handling
later
- do not error-check CreateDirectoryW; if failed,
just proceed as if the directory already existed
- print more debugging info where possible
Change-Id: I1162dae2c6b7524f14d8892047f9eb51831470dd
Closes #5611.
Change-Id: I78fe6aed6d0b120815339c0923c8a903990921d9
PiperOrigin-RevId: 205796307
|
|
|
|
|
|
|
|
|
|
|
| |
The conversion approach we were previously using is not stable - the resulting
offsets can differ based on what other things are going on on the same machine
at the same time.
By using an interface and passing it to the relevant places (and only computing
the offset once), we ensure that all conversions are consistent with each other.
PiperOrigin-RevId: 205787309
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 205751282
|
|
|
|
| |
PiperOrigin-RevId: 205729963
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
generate_interface_library is available
This way users of the Skylark API don't see this feature expanded.
RELNOTES: None.
PiperOrigin-RevId: 205704719
|
|
|
|
|
|
|
|
|
|
|
| |
--output graph`.
Implementation:
AIUI, currently the "edges' conditions" are lost [1] when the larger graph is initially constructed. It now does a second pass over dependency subgraph to find all the conditional edges and annotates them in dot output. This can be easily extended in other forms of output, but for now it only annotates edges in dot output.
[1]: https://github.com/bazelbuild/bazel/blob/32e9fee4e2192a340d0b1823538bf8e9fdf92b65/src/main/java/com/google/devtools/build/lib/query2/output/OutputFormatter.java#L745-L770
PiperOrigin-RevId: 205685823
|
|
|
|
| |
PiperOrigin-RevId: 205682761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 205665675
|
|
|
|
|
|
|
|
|
| |
Fixes #5331.
Change-Id: Idb01a3f206ed37992f200f7e0e51ed9831262613
RELNOTES: Code coverage is collected for Java binaries invoked from sh_test.
PiperOrigin-RevId: 205654442
|
|
|
|
|
|
|
| |
For now, implicitly convert "warn" to "loose".
RELNOTES: None.
PiperOrigin-RevId: 205652060
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 205646506
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
load() is not a function, but a keyword. It's already
documented in other places (https://docs.bazel.build/versions/master/skylark/concepts.html#loading-an-extension).
RELNOTES: None.
PiperOrigin-RevId: 205636295
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Providers that were wrapping CcLinkParamsStore now wrap CcLinkingInfo instead.
CcLinkParamsStore will be deleted in a future CL.
RELNOTES:none
PiperOrigin-RevId: 205629924
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
makes it possible to disable .d file scanning when input discovery is used
without allowing the usage of undeclared headers.
The way this is implemented relies on having a sand-boxed or remote execution
environment and simply removes undeclared files from discovered inputs. As a
result, the compiler cannot see them and can diagnose missing headers.
The input discovery itself cannot (usually) diagnose undeclared headers as it
is often implemented to be an over-approximation. It needs to find all used
headers, but it is allowed to find more. Diagnosing these additional headers
would not be useful.
RELNOTES: None.
PiperOrigin-RevId: 205628312
|
|
|
|
|
|
|
|
| |
It was missing the baseline coverage files, if any.
This is safe even if unknown commit is rolled back.
PiperOrigin-RevId: 205626149
|
|
|
|
|
|
|
|
| |
don't retry precondition_failed and
invalid_argument status codes.
RELNOTES: None
PiperOrigin-RevId: 205566423
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- refactor the BuildEventServiceClient interface to
report errors via StatusException and InterruptException.
- do the groundwork necessary to do retries based on
rpc status codes.
- improve the execution speed of the
BuildEventServiceStubbyClientTest from 1m5s to 5s.
RELNOTES: None
PiperOrigin-RevId: 205563431
|