| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
RELNOTES: Bazel supports including select Java 8 APIs into Android apps targeting pre-Nougat Android devices with --experimental_desugar_java8_libs
PiperOrigin-RevId: 196833987
|
|
|
|
|
|
|
|
| |
Fixes #5047
Closes #5209.
PiperOrigin-RevId: 196832678
|
|
|
|
|
|
|
|
|
|
|
| |
...by using the ShellEscaper rather than the ad-hoc "escaping"
in LocationExpander.
Fixes #5190. At least to the extend that a context-independent
quoting can work.
Change-Id: I858662861a2504139c19d773690aef2befc23948
PiperOrigin-RevId: 196832574
|
|
|
|
|
|
| |
TestsInSuiteValue serializable.
PiperOrigin-RevId: 196831698
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196825564
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 196824775
|
|
|
|
|
|
|
|
|
|
| |
whether FDO optimization is used (--fdo_optimize or --fdo_profile)
As part of the work of removing usage of c++ toolchain from CppConfiguration, CppConfiguration#isLLVMCompiler method needs to be removed.
Currently, CppConfiguration#shouldIncludeZipperInToolchain (former CppConfiguration#isLLVMOptimizedFdo) method uses the CppConfiguration#isLLVMCompiler method to determine whether the compiler is LLVM and conditionally includes the zipper if the compiler is LLVM and FDO optimization is in place.
Instead of rerouting the information on the compiler and FDO profile through FeatureFlagInfo, we make the inclusion of the zipper executable depend only on usage of FDO optimization.
PiperOrigin-RevId: 196819907
|
|
|
|
|
|
|
|
| |
This change makes the field match the semantics of the legacy mechanism that
is not open source. This is intended for migration only and the field should
not be used otherwise (that is why the field is deprecated).
PiperOrigin-RevId: 196817282
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Print the stacktrace of unexpected I/O errors in
StandaloneTestStrategy, to ease diagnosing the
root cause of the exception.
See https://github.com/bazelbuild/bazel/issues/4924
Without the stacktrace, all we see in BuildKite
is, for example:
```
ERROR: Caught I/O exception: java.io.IOException: C:/users/b/_bazel_b/bnp8s_vg/execroot/io_bazel/_tmp/b6bda2f0385d1152d3a7f550c6cc1938/_bazel_b/install/23a47abea50baae4d7e032437c1cecc9/_embedded_binaries/embedded_tools/jdk/bin/java.exe (Permission denied)
ERROR: C:/build/buildkite-worker-windows-java8-lfl8-1/bazel/google-bazel-presubmit/src/test/py/bazel/BUILD:71:1: Couldn't build file src/test/py/bazel/bazel_windows_test/test.log: failed: unexpected I/O exception: C:/users/b/_bazel_b/bnp8s_vg/execroot/io_bazel/_tmp/b6bda2f0385d1152d3a7f550c6cc1938/_bazel_b/install/23a47abea50baae4d7e032437c1cecc9/_embedded_binaries/embedded_tools/jdk/bin/java.exe (Permission denied)
```
The above log contains no information on what
exactly tried accessing java.exe and how, and why
it failed. With a stacktrace I'm hoping to shed
light on the culprit.
Change-Id: I4f3851cd1bc1b2b348217de5b41069591a8f4446
Closes #5207.
Change-Id: I792f4a36c1e31ca6332db2dc2d37bd8e597050b3
PiperOrigin-RevId: 196815410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cl enabled skylark rules to create build variables used for C++ compile
actions (in a limited form, e.g. build variables for modules are not exposed
etc).
Working towards #4571.
This is an encore of https://github.com/bazelbuild/bazel/commit/c4fc6201fdfa71993e2e9e295a946150e6990c75 after fixing memory regression
(CompileBuildVariables.getSafePathStrings fixed to return ImmutableList, which
has smaller memory footprint).
RELNOTES: None
PiperOrigin-RevId: 196797581
|
|
|
|
|
|
|
| |
Since it's not a provider, it doesn't need the Info suffix anymore.
RELNOTES:none
PiperOrigin-RevId: 196793557
|
|
|
|
|
|
|
|
| |
AbstractObjectCodecTest. I saw these tests causing errors in one version of the sequel unknown commit when testing detection of junk data, but not with this clean-up.
Also use the String codec provided in the context in AutoCodecProcessorTest.
PiperOrigin-RevId: 196756537
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This overrides --bazelrc and --[no]master_bazelrc regardless of order. Like --bazelrc and --[no]master_bazelrc, it cannot be mentioned in an rc file, this would be a contradiction. This flag is useful for testing, and for having a version-agnostic way to turn off all rc files, such as in the canonical command line reporting. Now that blazerc and bazelrc are separate, this is necessary.
If explicit values for --bazelrc or --master_bazelrc are provided which are now ignored, Bazel will warn the user.
#4502
Alternatives considered - We could avoid this flag but would need to have some well-documented, reusable list of the startup flags that effectively come to the same effect. This would be necessary in our integration tests and in the CommandLineEvent and other places where rc files need to be completely disabled for correctness. We decided that this startup option was more straightforward and usable for both users and Bazel devs: it shouldn't be used when more fine-grained control is needed, but provides warnings if users are likely to be confused by the outcome.
RELNOTES: None.
PiperOrigin-RevId: 196750704
|
|
|
|
|
|
|
|
|
| |
Extracts a class, InputArtifactData to hold the input data instead of using a raw map. This provides the flexibility needed to support both ActionFS and existing code so ActionFS does not need to rekey the input data.
Uses the smaller, getDeclaredIncludeSrcs instead of getAllowedDerivedInputs
when possible for staging optional inputs in ActionFS.
PiperOrigin-RevId: 196736703
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196726540
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196722758
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196722413
|
|
|
|
| |
PiperOrigin-RevId: 196719433
|
|
|
|
|
|
| |
Also pass the GraphInconsistencyReciever into SkyframeExecutor as a parameter.
PiperOrigin-RevId: 196716642
|
|
|
|
|
| |
RELNOTES: Remove vestigial java_plugin.data attribute
PiperOrigin-RevId: 196707434
|
|
|
|
|
|
| |
CommonCommandOptions to better facilitate certain kinds of benchmarking.
PiperOrigin-RevId: 196695342
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a command-line option which can be used to force Bazel to split up
very large events, e.g., events with hundreds of thousands of entries. This is
rare, but happens occasionally.
It would be better to control the maximum event size directly, but that is
significantly more difficult to do here.
PiperOrigin-RevId: 196690600
|
|
|
|
|
|
| |
with a package whitelist
PiperOrigin-RevId: 196688645
|
|
|
|
|
|
|
|
| |
it off after a release.
Discarding actions hasn't been shown to have a significant positive effect on heap memory usage, after careful research by mschaller@. It's holding back other projects (threading Fileset metadata through) and adding complexity, so it's time to kill it. Out of an abundance of caution, I'll keep actions in memory via a flag flip, then, if it sticks, I'll change the default, and then I'll unwire everything.
PiperOrigin-RevId: 196682768
|
|
|
|
|
|
| |
overridden by classes which would?ve otherwise thrown an NPE.
PiperOrigin-RevId: 196680390
|
|
|
|
|
|
|
|
| |
This class is not necessary anymore. We can use CcLinkParamsStoreImpl directly
which has been renamed to CcLinkParamsStore.
RELNOTES:none
PiperOrigin-RevId: 196656488
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Partly addresses #374.
Specifically allow !%^`"'&;<>?[]{|} in target and package names. It's actually
simpler now to declare what we don't allow. In target names:
0-31 (control characters)
58 ':' (colon)
92 '\' (backslash)
127 (delete)
In package names:
0-31 (control characters)
58 ':' (colon)
64 '@' (at-sign)
92 '\' (backslash)
127 (delete)
- '\' is a path segment separator on Windows, and allowing it can lead to
silent output file conflicts and - therefore - data corruption. We may be
able to allow it in the future, but I didn't want to make that call.
- ':' is a special character that Bazel interprets as the package name / target
name separator.
- '@' in package names can probably be allowed; at the beginning of a label it
indicates a workspace name, but not within a segment. We actually have some
tests that disallow it specifically, but those can probably just be deleted;
however, it does require a bit of investigation, so I decided to delay that
change.
It is possible that we don't correctly escape filenames in all cases. Also note
that the shell may require escaping for specific characters, and that Bazel
treats a single '*' (star) target name specially when given on the command
line.
RELNOTES: Bazel now allows almost all 7-bit ASCII characters in labels.
PiperOrigin-RevId: 196650651
|
|
|
|
|
|
|
| |
This is in preparation for fixing env handling as well as cache key (to use
env) computations in subclasses of SpawnAction.
PiperOrigin-RevId: 196626495
|
|
|
|
|
|
| |
(3-8x faster than StringCodec).
PiperOrigin-RevId: 196615858
|
|
|
|
|
|
|
|
|
| |
Use update() and other methods which properly respect the trimming
transition over those which don't. Avoid using the target configuration
if the configuration actually used by a target is available.
RELNOTES: None.
PiperOrigin-RevId: 196588405
|
|
|
|
|
|
|
|
| |
The local JDK is now the default --javabase and needs to be available for these
tests, see:
https://github.com/bazelbuild/bazel/commit/849df36c5ad31ebe8791c4228321c38c6d0ae56c
PiperOrigin-RevId: 196575260
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Caused a memory regression
*** Original change description ***
Expose cc_common.create_compile_build_variables
This cl enabled skylark rules to create build variables used for C++ compile
actions (in a limited form, e.g. build variables for modules are not exposed
etc).
Working towards #4571.
RELNOTES: None
PiperOrigin-RevId: 196566686
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196561473
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 196553226
|
|
|
|
|
|
|
|
| |
BuildOptions$DiffForReconstruction serializations are reached in this way, so we get better efficiency. Also, it was already a custom codec, so less new handrolling.
Also use serialization framework for FragmentClassSet, instead of doing serialization directly. Default FragmentClassSet should be a constant, so it will serialize down to a byte or three. Future changes can make all the classes constants as well, if we're getting misses on them.
PiperOrigin-RevId: 196546279
|
|
|
|
|
|
|
| |
It is a left over from long ago, and nothing should be using it as the
swift support is now via skylark rules and no longer native code.
PiperOrigin-RevId: 196541787
|
|
|
|
|
|
|
|
| |
prevents Bazel from crashing on an ErrorInfo with an exception from
ActionExecutionFunction, which can contain an action, and therefore contain a
NestedSet.
PiperOrigin-RevId: 196533301
|
|
|
|
|
|
| |
BuildOptions$OptionsDiffForReconstruction. The fingerprint uniquely identifies the "baseline" BuildOptions object and the checksum uniquely identifies the "overlay", so we don't need to incorporate the rest of the data.
PiperOrigin-RevId: 196532013
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196527806
|
|
|
|
| |
PiperOrigin-RevId: 196518906
|
|
|
|
|
|
|
| |
separate class
RELNOTES: None.
PiperOrigin-RevId: 196517537
|
|
|
|
|
|
|
| |
Since it's not a provider, it doesn't need the Info suffix anymore.
RELNOTES:none
PiperOrigin-RevId: 196505329
|
|
|
|
|
|
|
| |
Since it's not a provider, it doesn't need the Info suffix anymore.
RELNOTES:none
PiperOrigin-RevId: 196498526
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196492364
|
|
|
|
|
|
|
|
| |
For flaky tests, Bazel may have cached information about multiple test attempts. In that case, we might want to post all of them on a subsequent cache hit, rather than posting only the passing attempt.
We currently subclass TestResult inside Google, which overrides the new getCachedTestAttempts method.
PiperOrigin-RevId: 196491575
|
|
|
|
|
|
|
|
|
|
|
| |
This cl enabled skylark rules to create build variables used for C++ compile
actions (in a limited form, e.g. build variables for modules are not exposed
etc).
Working towards #4571.
RELNOTES: None
PiperOrigin-RevId: 196491567
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 196477775
|
|
|
|
|
|
|
|
|
| |
Create junctions to jar's directory when java launcher and its jar are under different drives
Fixed https://github.com/bazelbuild/bazel/issues/5135
Change-Id: I21c5b28f5f36c1fe234f8b781fe40d526db846cc
PiperOrigin-RevId: 196477704
|
|
|
|
|
|
|
|
|
| |
actually added for cc_library's include-attribute. For these, the same path is
present on the command line, but also ignored. For N of those directives, we
currently do O(N^2) prefix checks, which is unnecessarily expensive.
RELNOTES: None.
PiperOrigin-RevId: 196477307
|
|
|
|
| |
PiperOrigin-RevId: 196476639
|