| Commit message (Collapse) | Author | Age |
... | |
|
|
|
| |
PiperOrigin-RevId: 199627983
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current semantics of the flag is to allow BES upload to continue
past the nominal end of the build invocation, and possibly overlapping
a subsequent build invocation. This conflicts with file uploads, which
must read the file before it is removed or modified by the subsequent
build invocation. On Linux, we could just open a file handle, but this
isn't possible on Windows.
We decided to make the flag a no-op for now. Note that the default is
already set to false. We may resurrect this option in the future if
there's a strong use case for it, possibly with slightly different
semantics.
PiperOrigin-RevId: 199620392
|
|
|
|
|
|
|
| |
LSC is finished.
RELNOTES:none
PiperOrigin-RevId: 199619978
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 199619691
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 199619637
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression from v0.13. When the local disk cache flags were
unified into `--disk_cache`, it became impossible to override a default
cache location such that the cache became disabled. This prevents
canarying of remote execution in the presence of a default bazelrc that
enables the disk cache.
Fixes #5308
Closes #5338.
PiperOrigin-RevId: 199613922
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 199604462
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cl adds Skylark constants allowing users to specify which C++ action they
want for the feature configuration Skylark API. This is done by exposing a
Skylark file at @bazel_tools//tools/cpp:action_names.bzl.
Skylark api to the C++ toolchain doc:
https://docs.google.com/document/d/1g91BWJITcYw_X-VxsDC0VgUn5E9g0kRBGoBSpoO41gA/edit#.
Progress on #4571.
RELNOTES: None.
PiperOrigin-RevId: 199596778
|
|
|
|
|
|
|
| |
No longer needed.
RELNOTES:none
PiperOrigin-RevId: 199593828
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Report failures in TargetPatternFunction, rather than in its callers. Since we
can't distinguish between keep_going and nokeep_going modes, we otherwise end
up double-reporting errors. In the particular case that's covered by the
build_event_stream_test.sh, we end up reporting the same target pattern as both
skipped and failed.
Unfortunately, this means we cannot report whether the target pattern was
skipped or failed, so the pattern_skipped event is now unused (if we agree that
this is acceptable, I'll remove the corresponding infrastructure).
PiperOrigin-RevId: 199593700
|
|
|
|
|
|
| |
(minor) ActionFS now implements MetadataProvider.getInput
PiperOrigin-RevId: 199575194
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 199572597
|
|
|
|
| |
PiperOrigin-RevId: 199529974
|
|
|
|
|
|
|
|
|
| |
Change-Id: Icdabf559303bfac459e1a88ff44ca95298574361
Closes #5333.
Change-Id: Icdabf559303bfac459e1a88ff44ca95298574361
PiperOrigin-RevId: 199527673
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 199503117
|
|
|
|
|
|
|
| |
Crossbinary FDO optimization is a special form of AutoFDO which uses a synthetic profile to optimize targets without any profile. The synthetic profile will often be used as a default profile and will use .xfdo as suffix. It will be passed though option -fdo_optimize just like Autofdo profile. If .xfdo file is passed through -fdo_optimize in the same command line with other types of profiles, .xfdo file will be neglected.
RELNOTES: Build support for enabling cross binary FDO optimization.
PiperOrigin-RevId: 199501260
|
|
|
|
|
|
|
|
|
| |
That makes:
(a) merging PY2 and PY3 .runfiles impossible (which is incorrect anyway) and
(b) generated .py source files incompatible with 2to3 (src_version=PY2) - that's OK as we deprecate 2to3.
RELNOTES: n/a
PiperOrigin-RevId: 199491867
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 199467128
|
|
|
|
|
|
| |
This simplifies the code quite a bit.
PiperOrigin-RevId: 199427943
|
|
|
|
|
|
| |
Adds a helper class, ActionInputMap to do this with minimal wrapping overhead.
PiperOrigin-RevId: 199391251
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 199382344
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 199374368
|
|
|
|
|
|
|
| |
actually correct).
RELNOTES: None
PiperOrigin-RevId: 199373734
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
http://b/109733929 This CL breaks Blaze_CorpTest which must pass for Blaze's nightly candidate to form
*** Original change description ***
Add LabelLateBoundDefault to :coverage_support attribute
RELNOTES:none
PiperOrigin-RevId: 199352111
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
http://b/109733929
*** Original change description ***
Add LabelLateBoundDefault to :coverage_report_generator attribute
RELNOTES:none
PiperOrigin-RevId: 199308190
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|