| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
of directories and a file path containing more directories to blacklist. The current usage of PrecomputedValue#BLACKLISTED_PACKAGE_PREFIXES_FILE is overly general and is only meaningfully used by unit tests; in practice, the blacklist file path can never change over the lifetime of the Bazel server. Perform a minor simplifying refactor as a result of this.
RELNOTES: None.
PiperOrigin-RevId: 177164057
|
|
|
|
|
|
|
| |
CcToolchainProvider. Toolchain information must be removed from
CppConfiguration to allow the c++ rules to use hermetic platforms.
PiperOrigin-RevId: 177163880
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These enums were only used inside the class and
only to slighlty improve readability.
The Tokenize enum was a simple boolean.
The Options enum was implementing two boolean
flags, and it improved call-site readability at
the cost of implementation-site readability and
checking if the value is set via set-containment.
Change-Id: I3858ff0c67f89c8b2c5631e260ce79cd939c6eb1
PiperOrigin-RevId: 177155294
|
|
|
|
|
| |
Change-Id: I4bcc7c0024646b7d4372464f5290375d41702429
PiperOrigin-RevId: 177150713
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stop using LocationExpander.Options in
LocationExpander constructors, because the Options
semantics are confusing.
I also need the refactoring in order to extend the
expansion semantics: to support expanding to
absolute paths on Windows, where $(location)
should not expand to the (non-existent) runfiles
path, but to the absolute path the runfiles
symlink would point to.
See https://github.com/bazelbuild/bazel/issues/4171
Change-Id: Ie4d47ec3807bc3c6e39156efa1746b666f69f99c
PiperOrigin-RevId: 177147372
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that the SUCCESS status is often misunderstood to mean "zero exit",
even though this is clearly documented. I've decided to add another status for
non-zero exit, and use success only for zero exit to avoid this pitfall.
Also, many of the status codes are set, but never used. I decided to reduce the
number of status codes to only those that are actually relevant, which
simplifies further processing. Instead, we should add a string message for the
error case when we need one - we're not using it right now, so I decided not to
add that yet.
PiperOrigin-RevId: 177129441
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 177113477
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 177068047
|
|
|
|
| |
PiperOrigin-RevId: 177032673
|
|
|
|
|
|
|
|
|
| |
using FileValue, rather than FileStateValue, nodes as the roots of the rdep traversal.
This is incorrect e.g. when a .bzl file is a target of a symlink that is load'd from a BUILD file.
RELNOTES: None
PiperOrigin-RevId: 177018264
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks //javatests/com/google/devtools/intellij/blaze/plugin/aspect/java/soygenrule:SoyGenruleTest
*** Original change description ***
Create the output source jar in java_common.compile
and expose transitive source jars to Skylark.
Slightly refactor java classes to take in specific host javabase inputs and host java executable for creating the source jar, instead of always relying on fetching them from native java rules specific attributes.
Creating the output source jar in java_common.compile makes the behavior more similar to java_library.
Exposing the transitive_source_jars to Skylark helps with the Skylark migration fr...
***
RELNOTES: None.
PiperOrigin-RevId: 177015958
|
|
|
|
|
|
|
| |
I can't find whether ctx.run() actually exists. https://docs.bazel.build/versions/master/skylark/lib/ctx.html implies it doesn't.
RELNOTES: None.
PiperOrigin-RevId: 177005229
|
|
|
|
|
|
|
|
|
|
| |
Add CompactSkylarkInfo, which stores its values as an array instead of
a map. The space savings will probably not be dramatic because
providers usually have a limited amount of keys. But, there are a lot
of them!
Change-Id: Idd452a5e3982f773b1c5202c73f3d7031ec022c6
PiperOrigin-RevId: 176995376
|
|
|
|
|
| |
RELNOTES:
PiperOrigin-RevId: 176844836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and expose transitive source jars to Skylark.
Slightly refactor java classes to take in specific host javabase inputs and host java executable for creating the source jar, instead of always relying on fetching them from native java rules specific attributes.
Creating the output source jar in java_common.compile makes the behavior more similar to java_library.
Exposing the transitive_source_jars to Skylark helps with the Skylark migration from the old 'java' provider to JavaInfo.
Progress on #2614.
RELNOTES: transitive_source_jars is now exposed on JavaInfo.
PiperOrigin-RevId: 176844750
|
|
|
|
|
|
| |
The "$singlejar" attribute was removed in unknown commit.
PiperOrigin-RevId: 176826579
|
|
|
|
|
|
|
| |
Bazel is not reading its value anyway.
RELNOTES: None
PiperOrigin-RevId: 176768851
|
|
|
|
| |
PiperOrigin-RevId: 176759562
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 176700595
|
|
|
|
|
|
|
|
|
|
|
| |
CppHelper. In CppHelper, CcToolchainProvider and CppConfiguration are used
sepereately, allowing toolchain information to be removed from
CppConfiguration.
This is necessary to introduce hermetic toolchains, which require that
toolchain information be seperated from the configuration, into the c++ rules.
PiperOrigin-RevId: 176694160
|
|
|
|
|
|
|
|
|
| |
We already handle this properly in the normal case. However, when no attributes
from the new implementation of resource processing are specified, we fall back
to the old version, which didn't handle this.
RELNOTES: none
PiperOrigin-RevId: 176672081
|
|
|
|
|
|
|
| |
Part of #4128.
Change-Id: I1e043e7290912de5b246dbb8748cb2ad865ce38c
PiperOrigin-RevId: 176664440
|
|
|
|
|
|
|
|
|
| |
and #getDynamicMode to CcToolchainProvider and CppHelper.
Moving toolchain info out of CppConfiguration is required to use platform-based
toolchain resolution in the c++ rules.
PiperOrigin-RevId: 176662686
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 176659616
|
|
|
|
|
|
|
|
|
|
|
| |
Because CcProtoAspect.java also uses CcLibraryHelper.java to generate
linking action, but cc_proto_library doesn't have win_def_file
attribute.
Fix https://github.com/bazelbuild/bazel/issues/4126
Change-Id: I1b819c926c8025a49fea756bcaeb237824cb098e
PiperOrigin-RevId: 176653922
|
|
|
|
|
|
|
|
| |
The ResourceDependencies constructor takes in two NestedSet<Artifact> objects,
and I was putting them in the wrong order.
RELNOTES: none
PiperOrigin-RevId: 176648259
|
|
|
|
| |
PiperOrigin-RevId: 176647103
|
|
|
|
|
|
|
|
|
| |
So we actually test for override also from skylark repositories.
Fixes #3908.
Change-Id: I7650a17834a6915a73c89df46989f72aa2f56920
PiperOrigin-RevId: 176645218
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 176643685
|
|
|
|
|
|
|
| |
--experimental_enable_jvm_configuration_make_variables is not in effect.
RELNOTES: None.
PiperOrigin-RevId: 176641110
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 176635888
|
|
|
|
|
|
|
| |
When system_provide attribute is 1, Bazel assumes the runtime shared library is provided by system.
RELNOTES: None
PiperOrigin-RevId: 176632326
|
|
|
|
|
|
|
|
| |
Working on consolidating all mobile-install artifacts under label.name + "_mi/"
directory.
RELNOTES:None.
PiperOrigin-RevId: 176592620
|
|
|
|
|
|
|
|
|
| |
Currently we don't care about the list order of SpawnResults. However, we may care about the list order later. Also, if the equals() method for SpawnResults is ever changed then it may be problematic to return SpawnResults in a Set.
Aside: ActionResults use SpawnResults to calculate cumulative execution times for Actions, and may provide other metrics in future.
RELNOTES: None.
PiperOrigin-RevId: 176579460
|
|
|
|
|
|
|
|
|
| |
This is only relevant for things like 'bazel build //...' in workspaces that have a top-level //experimental directory. As such, this hardcoded exclusion is unlikely to be desired, especially by bazel users externally.
Fixes #3822.
RELNOTES: None
PiperOrigin-RevId: 176569346
|
|
|
|
|
|
|
|
|
|
| |
Package specifications can now be prefixed with `-` to
indicate negation: the specification `-//foo/bar/...`
excludes all packages under `//foo/bar` that would otherwise
have been matched.
RELNOTES: Package specifications can now be prefixed with `-` to indicate negation
PiperOrigin-RevId: 176551382
|
|
|
|
|
|
|
|
| |
This will instruct AAPT2 to produce conditional keep rules to allow for more aggressive code and resource shrinking.
RELNOTES[NEW]: Add --experimental_android_resource_cycle_shrinking option to allow for more aggressive code and resource shrinking.
PiperOrigin-RevId: 176530749
|
|
|
|
|
|
|
|
|
| |
uses of attribute-name string literals from MultiArchBinarySupport
This cleanup is a step in the right direction for exposing the apple linking API to Skylark -- supports must avoid calling ruleContext.getPrerequisites with attribute-name string literals; providers and TransitiveInfoCollections should come as inputs to the API.
RELNOTES: None.
PiperOrigin-RevId: 176525071
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows a flag_set to emit one flag when a feature is enabled, and a
different flag when that feature is disabled.
And while I was in there, I noticed and fixed a couple other issues:
1. env_set didn't actually implement with_feature, despite having the field in
its proto.
2. action_config implemented with_feature as an optional field, instead of
repeated field.
RELNOTES: None
PiperOrigin-RevId: 176510960
|
|
|
|
|
|
|
|
|
| |
cycles when loading platforms.
Part of #4128.
Change-Id: Ie55a91aaaec15d8eb537f59131fc2e69a8f9c251
PiperOrigin-RevId: 176509311
|
|
|
|
|
|
|
|
|
|
| |
This is needed for the ability to synthesize the correct remote
execution protos from a platform rule.
Part of #4128.
Change-Id: I7fa8acf45642a4df4e2beb1ba9c57c2536670486
PiperOrigin-RevId: 176504885
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For an action, whenever the status or strategy changes, reset
the timer. In this way, we show the time an action spent in the
current state, rather than the total time the action spent since
started. This might give a better picture of what is currently
going on in the system.
Fixes #4089.
Change-Id: I441337cf2eec58702889ac7a6a9ed150708e8c9d
PiperOrigin-RevId: 176497486
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 176496770
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `set` constructor used to be deprecated, but it was still possible to use
it by providing --incompatible_disallow_set_constructor=false.
It's still allowed to have `set` in parts of the code that are not executed, this will be deprecated later. You can check if your code is compatible with this future change by using the flag --incompatible_disallow_uncalled_set_constructor (currently the default is "false").
RELNOTES[INC]: The flag --incompatible_disallow_set_constructor is no longer
available, the deprecated `set` constructor is not available anymore.
PiperOrigin-RevId: 176491641
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is applying the version 1.1 of the specification (https://reproducible-builds.org/specs/source-date-epoch/)
where the only timestamp that Bazel puts in the final targets is overridden by the value of SOURCE_DATE_EPOCH.
This change also remove the legacy SOURCE_DATE_EPOCH handling which wasn't really following
the spec.
Note that Bazel itself tries hard to remove all timestamps from intermediary binaries and
overridde SOURCE_DATE_EPOCH in most action, which is a not according to the version 1.0 of the spec
but according to the expected change for version 1.1.
RELNOTES: SOURCE_DATE_EPOCH (https://reproducible-builds.org/specs/source-date-epoch/) can
be used to override the timestamp used for stamped target (when using --stamp).
Fixes #2240.
Change-Id: I074e7905fa6745cc706f7391340aeae9188909ca
PiperOrigin-RevId: 176489717
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When showing the current actions, the most interesting are those
that are currently being executed, not those that are waiting for
resources or otherwise in the process of being scheduled. Therefore,
show the executing actions at the top of the list. Also add more
visual hints to distinguish executing from non executing actions.
Screenshot
(14:51:21) [160 / 230] 32 actions, 11 running
Compiling lotsofwork/true986.c; 0s linux-sandbox
Compiling lotsofwork/true982.c; 0s linux-sandbox
Compiling lotsofwork/true983.c; 0s linux-sandbox
Executing genrule //lotsofwork:true975_c; 0s linux-sandbox
Compiling lotsofwork/true981.c; 0s linux-sandbox
Linking lotsofwork/true_999; 0s linux-sandbox
Linking lotsofwork/true_996; 0s linux-sandbox
Linking lotsofwork/true_998; 0s linux-sandbox
Compiling lotsofwork/true980.c; 0s linux-sandbox
Compiling lotsofwork/true98.c; 0s linux-sandbox
Executing genrule //lotsofwork:true974_c; 0s linux-sandbox
[Sched] Creating runfiles tree bazel-out/k8-fastbuild/bin/lotsofwork/true_974.runfiles
[Sched] Linking lotsofwork/true_997
[Sched] Linking lotsofwork/true_995
[Sched] Linking lotsofwork/true_99
[Sched] Linking lotsofwork/true_991 ...
Improves on #4089.
Change-Id: I1bc6636d5e53a16151023bba595e38259eb1ac88
PiperOrigin-RevId: 176483192
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 176423487
|
|
|
|
|
|
|
| |
Some flags are relatively immune to repeated mentions, since only the last mention ends up mattering, but in some cases, the values are accumulated. Expanding the same config twice may lead to surprising results, so provide a friendly warning.
RELNOTES: None
PiperOrigin-RevId: 176422758
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 176405273
|
|
|
|
|
|
|
| |
Configs are recursive, but let's be reasonable. If there's an absurdly long list of configs inheritance, warn about it. It is probably unnecessary, and might very well be unintentional and surprising to the user.
RELNOTES: None.
PiperOrigin-RevId: 176405183
|