| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
Closes #5649.
PiperOrigin-RevId: 205662376
|
|
|
|
|
|
| |
Closes #5598.
PiperOrigin-RevId: 205662280
|
|
|
|
|
|
|
|
|
|
| |
Make these tests run on Windows, but currently does not pass.
/cc @laszlocsomor
Closes #5652.
PiperOrigin-RevId: 205658932
|
|
|
|
|
|
|
|
|
| |
Fixes #5331.
Change-Id: Idb01a3f206ed37992f200f7e0e51ed9831262613
RELNOTES: Code coverage is collected for Java binaries invoked from sh_test.
PiperOrigin-RevId: 205654442
|
|
|
|
|
|
|
|
|
|
| |
When calling `bazel run` the command itself is executed by the
client. As an execve(2) replaces the program image, including
all buffered IO, flush all streams first. This will ensure that
the "Running command line" message is actually printed.
Change-Id: Ie18185bac4ed82a2725c75f97d3c64bd3003690b
PiperOrigin-RevId: 205652760
|
|
|
|
|
|
|
|
| |
Add Bazel Vision document.
Closes #5612.
PiperOrigin-RevId: 205652638
|
|
|
|
|
|
|
| |
For now, implicitly convert "warn" to "loose".
RELNOTES: None.
PiperOrigin-RevId: 205652060
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 205651683
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
due to a bug in our JDK9 build on mac we had to temporarily
rename the file. This has been fixed now. Both links point
to the exact same file.
RELNOTES: None
PiperOrigin-RevId: 205649421
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When switching to JDK9 we regressed on java build performance by about ~30%.
We found that when using parallel gc instead of G1 and disabling compact
strings for JavaBuilder, the java build performance is "only" 10% slower.
We additionally found JDK9 to have a significantly higher startup time.
This impacts the performance of tools like javac and tubine and we
believe that this accounts for most of the remaining overhead that can't
be explained by disabling G1 and compact strings.
java8 -version: 80ms
java9 -version: 140ms
java10 -version: 110ms
Additionally, we found that the number of modules shipped with the JDK
have a direct effect on the startup time. When building Java 10 with only
the 9 modules required by Bazel we find that the startup time reduces to
80ms (from 110ms) which is on par with Java 8.
We thus expect the regression to be fixed by a future migration to Java 10,
which should be done in one of the next Bazel releases.
== Some benchmark results ==
https://github.com/google/protobuf
$ bazel build :protobuf_java
Bazel 0.15.2: 4.2s
Bazel 0.16.0-rc2: 5.2s
This Change: 4.2s
https://github.com/jin/android-projects/tree/master/java_only
$ bazel build :module0
Bazel 0.15.2: 8.2s
Bazel 0.16.0-rc2: 11.5s
This Change: 9.1s
RELNOTES: None
PiperOrigin-RevId: 205647957
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
now that the bootstrap build uses the VanillaJavaBuilder it is compatible
with the host JDK's javac, and avoiding -Xbootclasspath/p makes the
bootstrap build more compatible with JDK 9.
See #5521
RELNOTES: N/A
PiperOrigin-RevId: 205605294
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 205447838
|
|
|
|
|
|
|
| |
for this upgrade.
RELNOTES=None.
PiperOrigin-RevId: 205437116
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
|
|
|
| |
errors encountered during the Skyframe part of hybrid globbing. The underlying transience of these is already handled by the Skyframe transience mechanism.
RELNOTES: None
PiperOrigin-RevId: 205403673
|
|
|
|
|
|
|
|
| |
are enabled before setting the corresponding build variables for the
crosstool. Such a conditional is unnecessary.
RELNOTES: None.
PiperOrigin-RevId: 205397072
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ByteStream's functions already close the
underlying stream.
See https://github.com/bazelbuild/bazel/commit/09d20311d982606093ed881d779bb05a5ee70ed3
Change-Id: Id389ef594946bfebb90ca66d97ea96f271b20331
Closes #5641.
Change-Id: Id389ef594946bfebb90ca66d97ea96f271b20331
PiperOrigin-RevId: 205395805
|
|
|
|
|
|
| |
This is in preparation for open sourcing our include scanning implementation.
PiperOrigin-RevId: 205386312
|
|
|
|
|
|
|
| |
RELNOTES[INC]:Labels in C++ rules' linkopts attribute are not expanded anymore
unless they are wrapped, e.g: $(location //foo:bar)
PiperOrigin-RevId: 205385711
|
|
|
|
|
|
|
|
|
| |
Exact API will continue to evolve, some specific functions
are experimental, but we can't really say that the concept
of rule is experimental.
RELNOTES: None.
PiperOrigin-RevId: 205383939
|
|
|
|
|
|
|
|
|
|
| |
Return a hash of a directory that is suitable to verify whether a repository
rule contained a good snapshot of source code. So certain aspects of the
directory, in particular ownership of the files, are deliberately not included
in the hash.
Change-Id: I1b35f7af47b376808acad3b6e54daaaec4f9ebfd
PiperOrigin-RevId: 205382020
|
|
|
|
|
|
| |
One tiny step after the other.
PiperOrigin-RevId: 205378056
|
|
|
|
|
|
|
|
| |
Feature configuration and toolchain are now mandatory arguments. Rule context
is no longer a positional argument.
RELNOTES:none
PiperOrigin-RevId: 205367825
|
|
|
|
| |
PiperOrigin-RevId: 205361498
|
|
|
|
|
|
|
| |
Since we no longer release the Bazel version without an embedded JDK.
RELNOTES: None
PiperOrigin-RevId: 205356986
|
|
|
|
|
|
| |
generation action, track all the sources that will be generated by the proto generator.
PiperOrigin-RevId: 205309842
|
| |
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 205288166
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 205281433
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
| |
Expose methods to enable shrinking resources via aapt2 proto.
Change-Id: I2379c81ea3573ac2314f0d3e8d638b53028f7949
|
|
|
|
|
|
|
| |
type.
RELNOTES: None.
PiperOrigin-RevId: 205237848
|
|
|
|
| |
PiperOrigin-RevId: 205236169
|
|
|
|
|
|
|
| |
Also add an execution requirement that allows disabling reporting to the CLI;
this will be used in a future change.
PiperOrigin-RevId: 205216096
|