| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 194799276
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 194798051
|
|
|
|
|
|
|
| |
This is necessary for subsequent changes to the apply method for diamond splitting, which will require apply() to take more than one argument. But it seems like the only reason LocationFunction ever extended Function was for tests and so this is an improvement on its own.
RELNOTES: None
PiperOrigin-RevId: 194796136
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the http response has a status other than 200 and
also has a Content-Length header set, then wait until
all content has been received before completing the user
promise.
In case of any errors, close the channel in order to make
sure it's not reused as we don't know what data is left
on the wire.
Closes #5101.
PiperOrigin-RevId: 194787393
|
|
|
|
| |
PiperOrigin-RevId: 194787067
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When trying to find a runfile on Windows:
1. First look for the runfiles MANIFEST and find runfile locations using this if it exists (current behavior).
2. If no MANIFEST file exists, look for runfiles in the runfiles directory (new behavior).
As part of this, remove setting RUNFILES_MANIFEST_ONLY for the benefit of test-setup.sh. Instead of telling it what to do, it decides what to do based on the observed state of the world. Launchers still set RUNFILES_MANIFEST_ONLY for the benefit of launched programs, since some may depend on this.
Fixes https://github.com/bazelbuild/bazel/issues/4962.
RELNOTES: Remote execution works for Windows binaries with launchers.
PiperOrigin-RevId: 194785440
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change getLauncher to return both a stripped and unstripped launcher binary
artifact under fission, instead of invoking getLauncher twice. This was
setting up two identical link actions that required later work to filter
out the redundant action in filterSharedActionsAndThrowActionConflict.
This becomes extremely inefficient under ThinLTO, where each launcher link
is actually 1 LTO indexing action, N LTO Backend actions, and 1 native link
action.
RELNOTES: None
PiperOrigin-RevId: 194781580
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks 70k targets in nightly
*** Original change description ***
CppDebugPackageProvider is useful for more than just C++, so rename it.
RELNOTES: None.
PiperOrigin-RevId: 194773896
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the half-done C++ runfiles library to
`//tools/cpp/runfiles`. (The Python and
Bash runfiles libraries are already under
`//tools/<language>/runfiles`.)
See https://github.com/bazelbuild/bazel/issues/4460
Change-Id: I1006f7f81462ea0e4b1de1adcdba89e386d4f9e7
Closes #5107.
Change-Id: I1006f7f81462ea0e4b1de1adcdba89e386d4f9e7
PiperOrigin-RevId: 194763392
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 194746481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no need for the cache to be on disk. Originally, there was a
desire to share this cache with other tools... but this never happened.
And, actually, because Bazel is in control of what it runs, it can just
inject the "cached" values into those tools via flags.
Instead, just store the cache in-memory. This avoids having to open and
read the cache on every single action that is locally executed on a Mac.
Results when building a large iOS app from a clean slate show up to a
1% wall time improvement on my Mac Pro 2013 and a reduction in the
variance of the measurements.
This change also gets rid of the OS check from the action execution's
critical path. There is not much use in checking this: if we instantiate
this by mistake, the actual calls will fail. But sometimes we want to
actually run this code on non-macOS systems (e.g. for unit-testing with
mocked tools), so we should allow that. And this change also ensures
that XcodeLocalEnvProviderTest builds and runs...
RELNOTES: None.
PiperOrigin-RevId: 194681802
|
|
|
|
|
|
|
| |
migration, when a flag is enabled.
RELNOTES:
PiperOrigin-RevId: 194630925
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks Bazel CI pipeline (pre and postsubmits) on all platforms: https://buildkite.com/bazel/bazel-bazel/builds/1785
Fixes https://github.com/bazelbuild/bazel/issues/5113
RELNOTES: None.
PiperOrigin-RevId: 194620643
|
|
|
|
|
|
| |
This allows incremental dexing to work with any Skylark rules that have implicit runtime dependencies. Rules should define a _toolchain attribute pointing to a Skylark toolchain. The toolchain should list all implicit runtime dependencies in a "runtime" attribute.
PiperOrigin-RevId: 194611124
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 194607978
|
|
|
|
|
|
|
|
|
|
|
| |
We want to be able to control how and when param files are used, and manual construction of param files prevents this. It should also be less code overall.
For this CL, when param files are used is unchanged, their format and encoding is unchanged. The flag name is also unchanged, except in some cases it was changed from (eg.) "--flagfile foo" to "--flagfile=foo".
However, the name of the param file is now derived from the primary output of the action (instead of manually controlled).
RELNOTES: None
PiperOrigin-RevId: 194607698
|
|
|
|
| |
PiperOrigin-RevId: 194602500
|
|
|
|
|
| |
RELNOTES:none.
PiperOrigin-RevId: 194598332
|
|
|
|
|
|
|
| |
jdeps proto without emitting any warning or error.
RELNOTES: none.
PiperOrigin-RevId: 194593178
|
|
|
|
|
|
|
|
|
|
| |
This brings BuildView's test configured target methods in closer
to the real thing, and makes tests behave better.
In particular, it enables trimming transitions to work.
RELNOTES: None.
PiperOrigin-RevId: 194586030
|
|
|
|
|
|
|
| |
RELNOTES: Bazel now supports running actions inside Docker containers.
To use this feature, run "bazel build --spawn_strategy=docker
--experimental_docker_image=myimage:latest".
PiperOrigin-RevId: 194582691
|
|
|
|
|
|
|
|
|
|
|
| |
rule must propagate
This allows native aspects which specifically require advertised providers to be applied to skylark rules.
Implementation to allow aspects to explicitly declare provider requirements will come later.
RELNOTES: Skylark rule definitions may advertise providers that targets of the rule must propagate.
PiperOrigin-RevId: 194581466
|
|
|
|
|
|
|
| |
CppHelper.getToolchainFromPlatformConstraints declare that they require a cc
toolchain.
PiperOrigin-RevId: 194580065
|
|
|
|
|
|
|
| |
CppHelper.getToolchainFromPlatformConstraints declare that they require a cc
toolchain.
PiperOrigin-RevId: 194567799
|
|
|
|
|
|
|
| |
CppHelper.getToolchainFromPlatformConstraints declare that they require a cc
toolchain.
PiperOrigin-RevId: 194561293
|
|
|
|
|
|
| |
Follow-up to https://github.com/bazelbuild/bazel/commit/bdb75bba00dbe97e9bb99db04844096f135f59ad
PiperOrigin-RevId: 194559167
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
corresponding features.
Therefore when both linking_mode_flags { mode: DYNAMIC } and feature { name:
"dynamic_linking_mode" } are provided, bazel will only take flags from the
feature. The same applies to mode: STATIC and static_linkin_mode feature
respectively. mode: MOSTLY_STATIC_LIBRARIES is covered under
dynamic_linking_mode for action "c++-link-dynamic-library". mode: FULLY_STATIC is handled separately.
This is needed to provide a way of incremental migration towards
legacy-flags-free crosstool.
RELNOTES: None.
PiperOrigin-RevId: 194556688
|
|
|
|
|
|
|
|
|
|
| |
Because trimming will impact these tests, rephrasing them so that they
don't depend on the exact configuration (but instead the actual
properties they're trying to test) allows them to pass when the trimming
transition is in place.
RELNOTES: None.
PiperOrigin-RevId: 194552473
|
|
|
|
|
|
|
|
| |
Allows subclasses to use different strategies for injecting Skylark
semantics.
RELNOTES: None.
PiperOrigin-RevId: 194546199
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 194540141
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 194536202
|
|
|
|
|
|
|
|
| |
late bound option defaults
BuildConfiguration.Fragment#lateBoundOptionDefaults() is going away soon, this flag is added to decouple its removal with the release process.
PiperOrigin-RevId: 194527657
|
|
|
|
|
|
|
| |
CppHelper.getToolchainFromPlatformConstraints declare that they require a cc
toolchain.
PiperOrigin-RevId: 194525607
|
|
|
|
|
|
|
| |
CppHelper.getToolchainFromPlatformConstraints declare that they require a cc
toolchain.
PiperOrigin-RevId: 194525415
|
|
|
|
| |
PiperOrigin-RevId: 194512971
|
|
|
|
| |
PiperOrigin-RevId: 194506134
|
|
|
|
| |
PiperOrigin-RevId: 194504697
|
|
|
|
|
|
|
| |
CppHelper.getToolchainFromPlatformConstraints declare that they require a cc
toolchain.
PiperOrigin-RevId: 194504473
|
|
|
|
| |
PiperOrigin-RevId: 194503531
|
|
|
|
|
|
| |
first one
PiperOrigin-RevId: 194491274
|
|
|
|
| |
PiperOrigin-RevId: 194487570
|
|
|
|
|
|
| |
--experimental_desugar_java8_libs
PiperOrigin-RevId: 194462758
|
|
|
|
|
| |
RELNOTES:
PiperOrigin-RevId: 194461881
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 194459347
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 194433721
|
|
|
|
|
|
|
|
|
|
|
| |
Rule authors frequently wants to make assertions on the parameter files their rule implementations have created. However, if they do not explicitly create parameter file write actions, or if indeed _there aren't_ any parameter file write actions inserted into the action graph, the tests will fail.
This CL puts an abstraction between the tests and obtaining their parameter files, allowing us to change the implementation without updating hundreds of lines of test code in the same CL.
Note that we can no longer sanely assert that the parameter file argument is inserted into the main command line, because the parameter file system controls both whether it is inserted and the name used. Those assertions have been removed where found.
RELNOTES: None
PiperOrigin-RevId: 194430947
|
|
|
|
| |
PiperOrigin-RevId: 194430205
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 194429584
|
|
|
|
|
|
|
|
|
| |
These flags cannot be specified under any circumstances - the parser treats
them as absent, and they can't be named in config_setting, etc. - so listing
them here doesn't help anyone.
RELNOTES: None.
PiperOrigin-RevId: 194419952
|
|
|
|
| |
PiperOrigin-RevId: 194413337
|