| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 182986489
|
|
|
|
|
|
|
|
| |
ImmutableSortedSet wherever possible, and use a known explicit ImmutableSortedSet in the case of two sets being equal. This is mainly a cosmetic cleanup for the sequel changes.
Also rename test-only methods in SkyframeExecutor to indicate that, and do a drive-by clean-up of a test that reported hard crashes confusingly because it wrapped RuntimeExceptions.
PiperOrigin-RevId: 182984572
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merged object files are needed when we use -flto-unit. It's created
during the LTO indexing step and needs to be passed to the final link.
LLVM already can create merged object files we just need to pass
"-Wl,-plugin-opt,obj-path=" into LLVM gold plugin.
"-flto-unit" emits IR to support LTO unit features needed for CFI (Control
Flow Integrity).
RELNOTES: Add support for merged object files needed for -flto-unit.
PiperOrigin-RevId: 182964781
|
|
|
|
| |
This reverts commit c7f2444e7ac4458aa58932ea3e9587c7036fd2e4.
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/4285
|
|
|
|
|
|
| |
Closes #4476.
PiperOrigin-RevId: 182941032
|
|
|
|
|
| |
Change-Id: Ie6070b01e7d004589064edc1f182baa6b6fac8b4
PiperOrigin-RevId: 182940613
|
|
|
|
|
|
|
|
| |
android_instrumentation_test's runfiles.
GITHUB: #903
RELNOTES: None.
PiperOrigin-RevId: 182940009
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 182937363
|
|
|
|
|
|
|
| |
JavaRuntimeInfo.
Change-Id: Ic338dc9b3e5efa2fee92dba722a46cab743db40c
PiperOrigin-RevId: 182919931
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not run "find & chmod" on the extracted files,
because:
(a) it's unnecessary, we can delete them in the
trap statement just fine, and
(b) it takes an impressive 20 minutes on Windows,
probably because process creation is a lot
slower on Windows than on Unixes and each
`chmod` runs as a subprocess of `find`
See https://github.com/bazelbuild/bazel/issues/4503
Change-Id: I47d97f00b875716997c197a51602fb6ea7728109
PiperOrigin-RevId: 182905086
|
|
|
|
|
|
|
| |
access.
Change-Id: I6041c51823fa52d6ae55dfe06afd1754ce05ab98
PiperOrigin-RevId: 182904580
|
|
|
|
|
|
|
|
| |
Fixes #3234.
Rollforward of commit dafe71390340224e06eab0ac7afcebb2f5219f5a with a bugfix
PiperOrigin-RevId: 182903117
|
|
|
|
|
|
|
|
|
|
|
| |
JavaRuleOutputJarsProvider.
Added tests for checking JavaRuleOutputJarsProvider state.
Moved all test cases related to JavaInfo to new file JavaInfoSkylarkApiTest.java
Created RuleBuilder inside JavaInfoSkylarkApiTest to reduce duplication of code.
RELNOTES:none
PiperOrigin-RevId: 182901118
|
|
|
|
|
|
|
|
|
|
| |
Bazel may also depend on external repositories that already contain
build files. When using http_archive from @bazel_tools also support
that use case, by supporting simply omitting `build_file` and
`build_file_contents`.
Change-Id: I40a9b85ae0aba850c73104d2e2fe7f7ee814e093
PiperOrigin-RevId: 182893460
|
|
|
|
|
|
| |
java.util.function.Predicate and move some code that was only called by TestFilter inside it.
PiperOrigin-RevId: 182884550
|
| |
|
|
|
|
|
|
| |
Fixes bazelbuild/bazel#4483
PiperOrigin-RevId: 182847474
|
|
|
|
|
|
| |
have already been changed to ConfiguredTargetAndTarget so there's fewer classes than I thought there would be.
PiperOrigin-RevId: 182839243
|
|
|
|
| |
PiperOrigin-RevId: 182837838
|
|
|
|
|
|
|
|
| |
Unfortunately, the getTag() function explicitly fails when it encounters a DTD
item, so we need to do a bit of custom handling instead.
RELNOTES: none
PiperOrigin-RevId: 182821046
|
|
|
|
|
|
|
|
|
| |
Bazel help output will now use the new categories by default, including for the generated html documentation at https://bazel.build/versions/master/docs/command-line-reference.html
Issue #3758 - this switches to the new categories, but the grouping is still by command, which leads to duplicate options
RELNOTES: None
PiperOrigin-RevId: 182815006
|
|
|
|
|
|
| |
Closes #4490.
PiperOrigin-RevId: 182812418
|
|
|
|
|
|
|
| |
Fixes #4170.
Change-Id: I308ee17eb769dcc6a94b90b1dd6cc2ccbe14e968
PiperOrigin-RevId: 182807196
|
|
|
|
|
|
|
| |
The idea is that rule sets should record what builtin providers (types, not instances) they use, as opposed to having a static registry the way we do for @SkylarkSignature builtins. (It'd be nice for the latter to not be static one day.)
RELNOTES: None
PiperOrigin-RevId: 182802492
|
|
|
|
| |
PiperOrigin-RevId: 182796843
|
|
|
|
|
|
|
| |
Part of #4442.
Change-Id: I49d6d851787727739f50348df2e2ef48392af479
PiperOrigin-RevId: 182795733
|
|
|
|
|
|
|
| |
This will serve as an alternative to --batch, leaving behind a server without state from the previous build.
RELNOTES: Introduces --[no]keep_state_after_build
PiperOrigin-RevId: 182778500
|
|
|
|
|
|
|
|
|
|
| |
Currently, we insist on all archives we download being compressed. But
technically, there is no reason compression is needed; handling plain
tar archives is no more complicated. So add that option as well; at the
very least, it makes testing more easy.
Change-Id: I1fddc95d5c80d195eb900ab74bf6403484f61da7
PiperOrigin-RevId: 182777193
|
|
|
|
|
|
|
|
| |
Regress on #3360.
We have reports of Bazel outputting warnings for generated files, which I have been able to reproduce. Apparently, Bazel gets stuck with an old FileContentsProxy for generated files, and is unable to recover.
PiperOrigin-RevId: 182772324
|
|
|
|
| |
PiperOrigin-RevId: 182767783
|
|
|
|
|
|
|
| |
Part of #4442.
Change-Id: I6debbf7cfdf560d2113e736176702c2cd889c0d2
PiperOrigin-RevId: 182763864
|
|
|
|
|
|
| |
owner and fix up BuildConfigurationValue.Key. ConfiguredTargetKey is going to need some modifications to AutoCodec: probably the long-awaited static "create" method.
PiperOrigin-RevId: 182630181
|
|
|
|
|
|
|
|
|
|
|
| |
Just shuffling code in the build() method to simplify future review.
1. Reuse result of getRootRelativePath()
2. Delay linkerInputs generation
3. allowLtoIndexing ? thinltoParamFile : null -> thinltoParamFile
it must be null if indexing is not allowed
RELNOTES: None
PiperOrigin-RevId: 182626938
|
|
|
|
|
|
|
| |
https://google.github.io/styleguide/javaguide.html#s3.4.2.1-overloads-never-split
RELNOTES: NONE.
PiperOrigin-RevId: 182626819
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 182579590
|
|
|
|
|
|
| |
into processRequest method in BuildTool. This is an extension of CL/181816980 and prevents pollution of BuildRequest.
PiperOrigin-RevId: 182576704
|
|
|
|
|
|
|
|
| |
into output files one by one this mostly means that we can start writing the next file while the previous one is still finishing up, and can read and write in parallel.
RELNOTES: None.
PiperOrigin-RevId: 182570961
|
|
|
|
| |
PiperOrigin-RevId: 182568806
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 182566009
|
|
|
|
|
|
| |
Also add a new appendFile method on Scratch.
PiperOrigin-RevId: 182558199
|
|
|
|
|
|
|
|
| |
constructor of a LanguageDependentFragment to use an ImmutableSet instead of a
HashSet.
RELNOTES: None.
PiperOrigin-RevId: 182555522
|
|
|
|
|
|
|
| |
An upcoming replacement to PathFragment will not have efficient segment semantics, causing code to become unnecessarily inefficient.
RELNOTES: None
PiperOrigin-RevId: 182553098
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 182546239
|
|
|
|
|
|
| |
This makes it clearer that the path fragments in question are relative *to the root*. Confusingly, when the root is absolute, the root relative fragment is also absolute. This makes it a tiny bit clearer that the path fragment may be absolute.
PiperOrigin-RevId: 182544893
|
|
|
|
|
|
|
| |
Part of #4442.
Change-Id: Ie263be75b85635717aa5670cf059891e644dfaee
PiperOrigin-RevId: 182537464
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 182528996
|
|
|
|
|
|
| |
path class.
PiperOrigin-RevId: 182526427
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks C++ on gcc 4.8.4 (specifically, TensorFlow: https://github.com/bazelbuild/bazel/issues/4474)
Fixes #4474
*** Original change description ***
When linking mostly-static Linux binaries, link libstdc++.a explicitly.
This allows libstdc++ to be statically linked, which is normally only
possible when invoking GCC as `g++` with the `-static-libstdc++` flag.
Fixes https://github.com/bazelbuild/bazel/issues/2840
See https://github.com/envoyproxy/envoy/issues/415 for additional
background and context.
cc @htuch (for Envoy) and @calpeyser @hlopko (who I talked to earlier about this)...
***
RELNOTES: None.
PiperOrigin-RevId: 182519445
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Local execution has an inherent race condition: if a user modifies a file while an action is executed, then it is impossible for Bazel to tell which version of the file was actually read during action execution. The file may have been modified before or after the tool has read it, or, in the worst case, the tool may have read both the original and the modified version. In addition, the file may be changed back to the original state before Bazel can check the file, so computing the digest before / after may not be sufficient.
This is a concern for both local and remote caches, although the cost of poisoning a shared remote cache is significantly higher, and is what has triggered this work.
Fixes #3360.
We solve this by keeping a reference to the FileContentsProxy, and using that to check for modificaitons before storing the cache entry. We output a warning if this check fails.
This change does not increase memory consumption; Java objects are always allocated in multiples of 8 bytes, we use compressed oops, and the FileArtifactValue currently has 12 bytes worth of fields (excl. object overhead), so adding another pointer is effectively free.
As a possible performance optimization on purely local builds, we could also consider not computing digests at all, and only use the FileContentsProxy for caching.
PiperOrigin-RevId: 182510358
|