| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
| |
non-existent code.
RELNOTES: None
PiperOrigin-RevId: 199307562
|
|
|
|
|
|
|
| |
Remove blaze references and add a missing "a".
RELNOTES: None.
PiperOrigin-RevId: 199300497
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the process, make it so that running an extra action attached to a
CppCompileAction does not change the state of the CppCompileAction (yes, this
happened: if include scanning was not done, topLevelModules would be changed)
There are two changes in behavior this will: introduce
1. topLevelModules will no longer be set if include scanning is not in effect, but that's okay: it's never read except when shouldPruneModules is true, and if that is true, #discoverInputsStage2() will set it.
2. Extra actions attached to CppCompileAction will not get .pcm files on their inputs that were not used by the compiler
RELNOTES: None.
PiperOrigin-RevId: 199285276
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 199280443
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 199256705
|
|
|
|
|
|
| |
RELNOTES[INC]: The $(ANDROID_CPU) Make variable is not available anymore. Use $(TARGET_CPU) after an Android configuration transition instead.
PiperOrigin-RevId: 199241622
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Discovered bug b/109675979 with feature, and flag flip may need to be reverted
*** Original change description ***
Remove support for --experimental_one_version_enforcement_use_transitive_jars_for_binary_under_test
PiperOrigin-RevId: 199223781
|
|
|
|
|
|
| |
in-progress reverse deps.
PiperOrigin-RevId: 199209256
|
|
|
|
|
|
|
|
|
|
| |
reference-equal on deserialization. We cannot just intern NestedSets because NestedSets with the same underlying children may still not be equal, so we wrap them in an object that does consider their children when calculating equality.
We wish to preserve the invariant that if NestedSets inside two different objects are reference-equal, they will continue to be reference-equal after deserialization. Not doing that causes bugs.
Unfortunately, because Artifact#equals does not take ArtifactOwner into account, this introduces a new bug (exposed via a disabled test here) where unequal singleton NestedSets may be considered equal. I will clean this up in the future by fixing Artifact#equals.
PiperOrigin-RevId: 199208045
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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: 199131390
|
|
|
|
|
|
|
| |
Next step will be to skip token allocation.
RELNOTES: None.
PiperOrigin-RevId: 199121625
|
|
|
|
| |
PiperOrigin-RevId: 199118944
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 199115199
|
|
|
|
|
|
|
| |
It doesn't use CcLinkParamsStore and CppLinkAction directly anymore.
RELNOTES:none
PiperOrigin-RevId: 199107747
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 199007753
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198911668
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198906931
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198906068
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198882702
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198880301
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
As the list of external repositories with their resolved information can
grow quite large, pretty print it, to make it easier for humans to inspect.
Change-Id: I34b2d6df84e52c07471a0bfaf97994cabd45feff
PiperOrigin-RevId: 198871353
|
|
|
|
|
|
| |
No longer needed since proto_library cannot be used for Java.
PiperOrigin-RevId: 198859993
|
|
|
|
|
|
| |
ActionExecutionValue.getAllFileValues.
PiperOrigin-RevId: 198807229
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unknown commit, we are using the JavaBuilder processor exemption list instead of
disabling strict deps for the affected rules outright. This narrows the degree
to which the exemption is applied, and prevents other strict deps violations
from accruing on targets that enable databinding.
Step 2 of 2; we needed the change to roll out in JavaBuilder first to be able
to fix up issues in the depot first before removing the exemption in Blaze.
See https://github.com/bazelbuild/bazel/commit/7edc5d49c8e764ab2bdf19e3a9fb58ea30fa708f for the original attempt.
PiperOrigin-RevId: 198793976
|
|
|
|
|
|
|
|
| |
I don't know much about most of this code, but there should be no functional
changes.
RELNOTES: none
PiperOrigin-RevId: 198773657
|
|
|
|
|
|
|
| |
Setting --config in .blazerc that overrode previous options in .blazerc was triggering unnecessary warnings. Fixed by only logging warnings when a user attempts to override an option specified on the command line.
RELNOTES: None.
PiperOrigin-RevId: 198756160
|
|
|
|
|
|
|
| |
skylarkbuildapi interface is annotated.
RELNOTES: None.
PiperOrigin-RevId: 198743504
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198735582
|
|
|
|
|
|
| |
attribute.
PiperOrigin-RevId: 198735448
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 198728350
|
|
|
|
|
|
| |
and remove unused repositoryName field from BuildConfiguration.
PiperOrigin-RevId: 198723339
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
--experimental_one_version_enforcement_use_transitive_jars_for_binary_under_test
PiperOrigin-RevId: 198601057
|
|
|
|
|
|
|
|
| |
* is not an allowed file system character on Windows and checking if it's a
directory or file for the wilcard check would throw an InvalidPathException.
RELNOTES: None
PiperOrigin-RevId: 198595138
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These restrictions were originally put in place to prevent things like
android_binary from being used as dependencies of android_library. However, it
doesn't actually work - the restrictions are all ORed together, and that means
rules that are of the allowed kind OR that have a JavaProvider are allowed.
Since all android_binary targets presumably have Java providers, they are
presumably all allowed.
Slightly expand these restrictions by also allowing rules that have Android
resource and asset providers. This will allow us to use Skylark rules to only
inherit assets and resources from a target, but not anything else.
I don't anticipate this expansion will have unwanted side effects, since
virtually all Android targets already have Java providers anyway.
RELNOTES: none
PiperOrigin-RevId: 198593996
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|