| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
functionality in WORKSPACE rules.
RELNOTES: None
PiperOrigin-RevId: 199332092
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RuleClass.Builder now allows authors to specify whether a rule's targets
can add additional constraints on the execution platform, and to declare
additional constraints for all targets of that rule.
Targets which support this now have an attribute,
"exec_compatible_with", which supports specifying additional constraints
that the execution platform used must match.
This attribute is non-configurable. It will only affect execution
platforms used during toolchain resolution.
Part of #5217.
Change-Id: Id2400dbf869a00aa2be3e3d2f085c2850cd6dc00
Closes #5227.
Change-Id: If7d55f08f7f44bc7d7f6dfec86a3e6bcd68574b9
PiperOrigin-RevId: 199326255
|
|
|
|
|
|
|
|
| |
class is allowed to be serialized in the current context. A codec can now add an explicitly allowed class that can be serialized underneath it (via SerializationContext#addExplicitlyAllowedClass), and that class's codec can check that it is explicitly allowed (via SerializationContext#checkClassExplicitlyAllowed). It is a runtime crash if a codec checks that it was explicitly allowed and finds that it wasn't. Thus, if PackageCodec is invoked without it having been explicitly allowed, we will crash, preventing Package from sneaking into a value it shouldn't be in.
This is only enabled if the codec is memoizing.
PiperOrigin-RevId: 199317936
|
|
|
|
|
|
|
|
|
|
| |
There's only one Token and it gets reused.
This reduces the memory usage of the lexer. Parsing time seems to be 5%-10%
faster with this change on a large file. This makes little difference on the
overall performance of Bazel though.
RELNOTES: None.
PiperOrigin-RevId: 199310860
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
way to remap references to repositories within an external repository by another name. This CL only adds the mappings to the Package object, but it does not actually enable the reassignments.
Example usage (in a WORKSPACE file):
local_repository(
name = ?a?,
path = ?../a?,
repo_mapping = {?@x? : ?@y?}
)
This change also creates a new SkyKey which represents the mappings. This is to prevent all packages from depending on the external package, and instead depending just on the mappings. i.e. a change to the WORKSPACE file that does not touch the mappings shouldn't cause a reload of the package.
RELNOTES:None
PiperOrigin-RevId: 199187963
|
|
|
|
|
|
|
| |
It's been about a year since these haven't been necessary.
RELNOTES: None.
PiperOrigin-RevId: 199178625
|
|
|
|
|
|
| |
needed: we can get the ConfiguredTargetKey directly from the TargetCompletionKey. Since that was the only use of the actual value in EvaluationProgressReceiver#evaluated, remove it, instead just provide a boolean enum that gives whether or not evaluation succeeded.
PiperOrigin-RevId: 199178047
|
|
|
|
|
|
|
| |
Crosstool selection will be based solely on --cpu and --compiler options.
RELNOTES: Option --glibc is removed, toolchain selection relies solely on --cpu and --compiler options.
PiperOrigin-RevId: 199156131
|
|
|
|
|
|
| |
ConfiguredTarget. Since ConfiguredTarget does not implement equals(), reference equality has been used until now, and this is not valid for the case where the ConfiguredTarget has been deserialized.
PiperOrigin-RevId: 199133926
|
|
|
|
|
|
| |
toolchains attribute.
PiperOrigin-RevId: 199133235
|
|
|
|
| |
PiperOrigin-RevId: 199126212
|
|
|
|
|
|
|
| |
Next step will be to skip token allocation.
RELNOTES: None.
PiperOrigin-RevId: 199121625
|
|
|
|
| |
PiperOrigin-RevId: 199118944
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL is a followup to c868c47. It is
intended to fix #5296. The immediate
problem in that issue is that remote caching finds a tree artifact in an input
runfiles tree without metadata in the cache. The metadata isn't there because
the runfiles artifacts are now all behind a middleman action, and
ArtifactFunction didn't propagate tree artifact values through middlemen. This
change fixes the problem by adding a tree artifact's self data value to the
values carried through to dependent actions.
Remote caching with tree artifact inputs seems to have been working mostly by
accident. (Evidence: it wasn't tested, and remote execution of actions with tree
artifact inputs results a Java traceback before and after
c868c47.) This CL is only really a bandaid to
return to the old "working" state. If remote execution wants to start supporting
tree artifacts properly in the future, we'll likely need to carry the tree
artifact child data through middleman actions, too.
Closes #5299.
Change-Id: I2e07d4fca0f6d2d34d97b7edb27f9d0063776225
PiperOrigin-RevId: 199079382
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces concurrent downloads of action outputs
for remote caching/execution. So far, for an action we would
download one output after the other which isn't as bad as it
sounds as we would typically run dozens or hundreds of actions
in parallel. However, for actions with a lot of outputs or graphs
that allow limited parallelism we expect this change to positively
impact performance.
Note, that with this change the AbstractRemoteActionCache will
attempt to always download all outputs concurrently. The actual
parallelism is controlled by the underlying network transport.
The gRPC transport currently enforces no limits on the concurrent
calls, which should be fine given that all calls are multiplexed
on a single network connection. The HTTP/1.1 transport also
enforces no parallelism by default, but I have added the
--remote_max_connections=INT flag which allows to specify an upper
bound on the number of network connections to be open concurrently.
I have introduced this flag as a defensive mechanism for users
who's environment might enforce an upper bound on the number of open
connections, as with this change its possible for the number of
concurrently open connections to dramatically increase (from
NumParallelActions to NumParallelActions * SumParallelActionOutputs).
A side effect of this change is that it puts the infrastructure
for retries and circuit breaking for the HttpBlobStore in place.
RELNOTES: None
PiperOrigin-RevId: 199005510
|
|
|
|
|
|
|
|
|
|
| |
Supporting tools in inputs introduces a slow linear scan. Such tools should be moved to the 'tools' attribute. If --incompatible_no_support_tools_in_action_inputs is set the inputs are scanned, but a helpful error message is issued to the user.
Eventually we will remove the slow scanning. Errors will surface in the execution phase instead of during analysis, and the resulting error messages will be less obvious.
RELNOTES: None
RELNOTES[INC]: With --incompatible_no_support_tools_in_action_inputs enabled, Skylark action inputs are no longer scanned for tools. Move any such inputs to the newly introduced 'tools' attribute.
PiperOrigin-RevId: 198996093
|
|
|
|
|
|
|
| |
Always generating source jars can lead to action conflicts.
RELNOTES: None
PiperOrigin-RevId: 198994272
|
|
|
|
|
|
| |
Actual class to be removed in a later change.
PiperOrigin-RevId: 198937695
|
|
|
|
|
|
|
|
| |
If multiple trimming transition factories are added, they are composed in
the order they were added.
RELNOTES: None.
PiperOrigin-RevId: 198934666
|
|
|
|
|
|
|
| |
This serves a regression test of a previous breakage which broke SkylarkCallable method of FilesToRunProvider.
RELNOTES: None.
PiperOrigin-RevId: 198915920
|
|
|
|
|
|
| |
nodes in ConfiguredTargetQueryEnvironemnt. This lets us support recursive target patterns with cquery.
PiperOrigin-RevId: 198879650
|
|
|
|
| |
PiperOrigin-RevId: 198877280
|
|
|
|
|
|
|
|
|
|
|
| |
java_common.compile doesn't generate the output source jar when a source jar is
the only input for the compilation. This is wrong because the source jar can
include APT generated sources. It is also inconsistent with java_library and
leads to inconsistent Skylark rules where a declared output will not always have a
generating action.
RELNOTES: None.
PiperOrigin-RevId: 198872718
|
|
|
|
|
|
|
| |
We thought we had a test for this, but it turns out we didn't. Add one now.
RELNOTES: none
PiperOrigin-RevId: 198772854
|
|
|
|
|
|
| |
attribute.
PiperOrigin-RevId: 198735448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This prevents an invalid flag like `resources:assets:AndroidManifest.xml:::local.bin` to match, as with the case in https://github.com/bazelbuild/bazel/issues/5214
where the R.txt file is missing (shouldn't happen, but let's be defensive)
Error message:
```
.. invalid DependencyAndroidData: bazel-out/android-armeabi-v7a-fastbuild/bin/external/androidsdk/com.android.support/_aar/unzipped/resources/support-compat-25.0.0/res:bazel-out/android-armeabi-v7a-fastbuild/bin/external/androidsdk/com.android.support/_aar/unzipped/assets/support-compat-25.0.0/assets:bazel-out/android-armeabi-v7a-fastbuild/bin/external/androidsdk/com.android.support/support-compat-25.0.0_processed_manifest/AndroidManifest.xml:::bazel-out/android-armeabi-v7a-fastbuild/bin/external/androidsdk/com.android.support/support-compat-25.0.0_symbols/local.bin is not in the format 'resources[#resources]:assets[#assets]:manifest:r.txt(:symbols.zip?):symbols.bin'
```
RELNOTES: None.
PiperOrigin-RevId: 198724816
|
|
|
|
|
|
|
| |
This was a workaround created to deal with duplicated symbol errors, but there are now better ways to avoid them than using this attribute.
RELNOTES: non_propagated_deps has been removed from objc_library and apple_binary.
PiperOrigin-RevId: 198620886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
without reading the CROSSTOOL file.
As we want to reroute selecting the toolchain from CROSSTOOL through cc_toolchain, cc_toolchain_suite should have all the necesarry information for obtaining the cc_toolchain label without accessing the CROSSTOOL file.
In order to do that, besides the existing <toolchain.targetCpu>|<toolchain.compiler>, we add <cpu> type of key in 'toolchains' attribute of cc_toolchain_suite.
Now the selection of cc_toolchain label goes as follows:
1. Return toolchains[<cpu>|<compiler> if it exists
2. Return toolchains[<cpu>] if it exists
3. Fall back to the previous state: return toolchains[<toolchain.targetCpu>|<toolchain.compiler>]
RELNOTES: None.
PiperOrigin-RevId: 198588849
|
|
|
|
|
|
|
|
|
| |
This new flag can be used to forcibly enable dSYM generation for dbg
apple builds, which is especially useful for debugging in remote
builds, which may require the use of dSYMs.
RELNOTES: Added --apple_enable_auto_dsym_dbg flag.
PiperOrigin-RevId: 198577541
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 198565423
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This used to work more smoothly. But the introduction of
ConfiguredTargetAndData adds a Precondition check:
https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/skyframe/ConfiguredTargetAndData.java;l=68?q=ConfiguredTargetAndData
that crashes if innerConfigurationKey is null. The only
way that can happen is when reading a bad label, which
Bazel assumes (incorrectly in this case) to be a
null-configured source file.
Good times.
PiperOrigin-RevId: 198557148
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
classes are not equal.
Also validate that there are no tree and file artifacts with the same exec path.
Fixes #4668.
Closes #5284.
Change-Id: Id97c0407a476a5bfc697b4ca7b858e3d0c0f8c75
PiperOrigin-RevId: 198540425
|
|
|
|
| |
PiperOrigin-RevId: 198535546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
According to a post-submit regression test, this
commit increased Bazel's memory usage slightly
beyond some threshold. That event prompted me to
consider and question the necessity of this
commit.
My goal is to make Bazel work on Windows without
requiring MSYS, failing the build only if an
action is a shell action. Toolchainifying the
shell is related to, but not required by this
effort. What is required is to fail the build when
Bazel tries to create a shell action but the shell
is missing, and we have that already with
ShToolchain.getPath (which only considers the
ShellConfiguration fragment).
What's missing for my goal is to reimplement
hardcoded shell actions
(i.e. SpawnAction.builder().setShellCommand(...))
without using the shell where possible.
*** Original change description ***
shell toolchain: genrule now uses it
genrule() now uses the shell toolchain (as well as
the ShellConfiguration config fragment) to look up
the shell interpreter's path.
Also the CommandHelper no longer looks up the
shell interpreter's path itself. Instead its ctor
takes the path as an argument. This allows
supporting rules that already use the shell
toolchain and rules that still only consider the
configuration fragment.
With these changes genrule() is now able to use
the shell interpreter registered as a toolchain,
even if there's no `--shell_executable` flag
specified (or its value is empty).
Subsequent commits will migrate more and more
rules to depend on the shell toolchain.
This commit takes us closer to:
1. be able to detect the local shell interpreter's
location, especially when it's not the default
/bin/bash
2. be able to define different shell toolchains
(different interpreter paths) for remote builds
3. gracefully fail the build if the machine has no
shell installed but the action graph included a
shell action
See https://github.com/bazelbuild/bazel/issues/4319
Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7
Closes #5282.
***
RELNOTES: none
PiperOrigin-RevId: 198527351
|
|
|
|
|
|
|
|
| |
When deriving the Java package from path to a target, actually derive it from
the path to the entire target, not just the target's BUILD file.
RELNOTES: none
PiperOrigin-RevId: 198426047
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Much earlier, I made a change that allowed passing assets without resources to
aapt packaging. Do the same for aapt2 packaging too.
The busybox seems to be expecting compiled symbols, so compile assets and pass
the compiled version in. (Compiling assets doesn't save any time, but doesn't
cost much either, and means that we'll eventually be able to phase out the
parsed form entirely. Adapting the Busybox to take parsed assets would probably
work too, but getting the code to handle it would be really messy.)
RELNOTES: none
PiperOrigin-RevId: 198417111
|
|
|
|
|
|
| |
This is a prequisite to removing cc_toolchain_type entirely.
PiperOrigin-RevId: 198402472
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
genrule() now uses the shell toolchain (as well as
the ShellConfiguration config fragment) to look up
the shell interpreter's path.
Also the CommandHelper no longer looks up the
shell interpreter's path itself. Instead its ctor
takes the path as an argument. This allows
supporting rules that already use the shell
toolchain and rules that still only consider the
configuration fragment.
With these changes genrule() is now able to use
the shell interpreter registered as a toolchain,
even if there's no `--shell_executable` flag
specified (or its value is empty).
Subsequent commits will migrate more and more
rules to depend on the shell toolchain.
This commit takes us closer to:
1. be able to detect the local shell interpreter's
location, especially when it's not the default
/bin/bash
2. be able to define different shell toolchains
(different interpreter paths) for remote builds
3. gracefully fail the build if the machine has no
shell installed but the action graph included a
shell action
See https://github.com/bazelbuild/bazel/issues/4319
Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7
Closes #5282.
Change-Id: I0674c7e2d5917643d87b48b19a1cb43e606ad2f7
PiperOrigin-RevId: 198394021
|
|
|
|
|
|
|
|
|
|
|
| |
With the recording of the results of repository rules (that
eventually will lead to an implementation of the WORKSPACE.resolved
proposal) bazel started writing out lengthy Skylark values. To make
this file more readable for humans, add a Skylkark printer that
does at least some basic line breaking and indenting.
Change-Id: I469d029421df9212b43747509dd17bd6c64da4a8
PiperOrigin-RevId: 198389112
|
|
|
|
|
|
| |
We now track Causes instead of plain Labels, which will allow us to do better reporting in the future. Add basic tests.
PiperOrigin-RevId: 198380468
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198378682
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 198364550
|
|
|
|
|
|
| |
WANT_LGTM=all
RELNOTES:none
PiperOrigin-RevId: 198269370
|
|
|
|
| |
PiperOrigin-RevId: 198262096
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198107604
|
|
|
|
|
|
|
| |
This is no longer meaningful with the turndown of
(C++) LIPO.
PiperOrigin-RevId: 198092974
|
|
|
|
| |
PiperOrigin-RevId: 198081030
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Roll forward with fix:
I was assuming that R.txt and symbols files are always set, but they can be
null in some cases (especially in the old data processing pipeline). Properly
handle them here.
RELNOTES: none
PiperOrigin-RevId: 198075743
|
|
|
|
|
|
|
|
| |
Fixes #5263
RELNOTES: execution strategies line no longer handles differently the case
where all processes have the same strategy.
PiperOrigin-RevId: 198057496
|
|
|
|
| |
PiperOrigin-RevId: 198053509
|