| Commit message (Collapse) | Author | Age |
... | |
|
|
|
| |
PiperOrigin-RevId: 194999124
|
|
|
|
| |
PiperOrigin-RevId: 194998981
|
|
|
|
| |
PiperOrigin-RevId: 194985259
|
|
|
|
| |
PiperOrigin-RevId: 194985157
|
|
|
|
|
|
|
|
|
| |
for resources.
Refactor: Move the resource compilation out of the treewalk.
RELNOTES: None
PiperOrigin-RevId: 194982664
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 194979843
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Still causes a memory regression
*** Original change description ***
Consolidating start/end lib archive expansion Take 2
Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command l...
RELNOTES:
Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent.
PiperOrigin-RevId: 194970156
|
|
|
|
| |
PiperOrigin-RevId: 194967939
|
|
|
|
|
|
|
|
|
| |
This helps the Skylark interpreter to not depend on Bazel concepts, though it adds a temporary dependency of Skylint on packages/. The fix for that will be to create a Build API interface for BazelLibrary (e.g., "BazelLibraryAPI").
Refactored some GlobalFrame construction logic to be more uniform. Instead of constructing a whole Environment just to get a frame, we build the frame directly, using ImmutableMap.Builder to accumulate bindings. This convention may further change once we convert MethodLibrary and the like to @SkylarkGlobalLibrary, but for now it's more readable.
RELNOTES: None
PiperOrigin-RevId: 194960824
|
|
|
|
| |
PiperOrigin-RevId: 194960802
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 194960076
|
|
|
|
|
|
|
|
| |
This deprecates the old NativeProvider pattern.
The new pattern is demonstrated using AppleStaticLibraryInfo.
RELNOTES: None.
PiperOrigin-RevId: 194956883
|
|
|
|
|
|
|
| |
Spawns can contain param files in the form of virtual action inputs. Sandboxed runners must write these prior to execution of the action.
RELNOTES: None
PiperOrigin-RevId: 194951208
|
|
|
|
| |
PiperOrigin-RevId: 194895469
|
|
|
|
|
|
|
|
|
|
| |
node's in-progress data should be forgotten, and its evaluation should be restarted from scratch, as if it were freshly created/dirtied. To guard against this happening unexpectedly, any such events are passed to a GraphInconsistencyReceiver, which can verify that the SkyFunction is behaving properly.
This is the first change in a series to permit action rewinding when it is discovered that a previously generated input file is no longer available. When an action detects that one of its inputs is unusable, it can return this sentinel value, causing it to be re-evaluated from scratch. Follow-up changes will make the node corresponding to the input, and the node corresponding to the action that generated the input, dirty when this happens, causing the upstream action to be re-run, regenerating the desired input.
Currently works for builds that do not keep edges, although follow-ups may make this possible for all builds.
PiperOrigin-RevId: 194863097
|
|
|
|
|
|
|
| |
contains incompatible versions of deps
RELNOTES: Add support for reporting an error if android_test.binary_under_test contains incompatible versions of deps
PiperOrigin-RevId: 194857840
|
|
|
|
|
|
|
| |
This isolates the API from the implementation.
RELNOTES: None.
PiperOrigin-RevId: 194850527
|
|
|
|
|
|
|
|
| |
Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command l...
RELNOTES:
Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent.
PiperOrigin-RevId: 194847987
|
|
|
|
|
|
|
| |
This still leaves this type documented until a later time, but it makes the type's name explicitly defined (instead of inferred from the class name)
RELNOTES: None.
PiperOrigin-RevId: 194838958
|
|
|
|
|
|
| |
remote write should block on the provided future.
PiperOrigin-RevId: 194836516
|
|
|
|
|
|
| |
targets to upstream cc_library targets.
PiperOrigin-RevId: 194816009
|
|
|
|
|
|
|
|
|
|
|
| |
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: 194809530
|
|
|
|
|
|
|
|
| |
...to mark that the file as used. In this way, the file stamps
in the cache can be used to indicate which files are still in use.
Change-Id: I4a0f0865112da76476941e487434fffd36c0853a
PiperOrigin-RevId: 194804545
|
|
|
|
| |
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
|