| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
- Replace the existing Retrier with Retrier2.
- Rename Retrier2 to Retrier and remove the old Retrier + RetryException
class.
RELNOTES: None.
PiperOrigin-RevId: 177835070
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/4028
Closes #4029.
PiperOrigin-RevId: 177813419
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JavaSkylarkApiProvider will be deprecated soon and replaced by JavaInfo.
Methods exposed:
NestedSet<Artifact> getTransitiveSourceJars()
NestedSet<Artifact> getTransitiveRuntimeDeps()
NestedSet<Artifact> getTransitiveDeps()
Also created helped method to eliminate all duplication code and refactored some methods with is.
RELNOTES:none
PiperOrigin-RevId: 177804645
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a roll-forward of https://github.com/bazelbuild/bazel/commit/e8d32b7c922f65539b74357711d5ad6b70934115, which broke some genrules, but without
some cleanup changes which I'm submitting separately, and with a fix for the
bug.
The problem was that I switched from withExecLocations(labels) to
withExecLocations(); the original code was in CommandHelper, and the new
code in GenRuleBase, so this was not obvious.
Also, we didn't have test coverage for this case - note that the specified
labels are _added_ to the default map of labels, rather than replacing the
default map of labels. This only matters if the dependent rule provides a
GenRuleSourcesProvider, which only a single (Google-internal) rule does.
PiperOrigin-RevId: 177802902
|
|
|
|
|
|
|
| |
RELNOTES:
First argument of 'load' must be a label. Path syntax is removed.
(label should start with '//' or ':').
PiperOrigin-RevId: 177802628
|
|
|
|
| |
PiperOrigin-RevId: 177708823
|
|
|
|
|
|
|
| |
* Extend RuleClassNamePredicate to be both inclusive or exclusive
* Attribute uses RuleClassNamePredicate instead of Predicate<RuleClass>
PiperOrigin-RevId: 177656647
|
|
|
|
|
|
|
| |
each Action.
RELNOTES: None.
PiperOrigin-RevId: 177652741
|
|
|
|
|
|
|
|
|
| |
AndroidSemantics is for "pluggability". Defining static constants on the
interface does not do that. Furthermore, output group names are not something
we would want to change between internal and external.
RELNOTES: None
PiperOrigin-RevId: 177632488
|
|
|
|
|
|
|
| |
Fixes #4173.
RELNOTES: None.
PiperOrigin-RevId: 177582228
|
|
|
|
|
|
|
| |
respecting the one version for java test flag, and enforcing one version on the _deploy.jar
RELNOTES: n/a
PiperOrigin-RevId: 177525487
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks lots of web_test targets (b/69963706)
*** Original change description ***
Implemented fix for case when 'use_testrunner' attribute works interconnected with 'main_class' in java_test rule.
for manual testing I used BUILD file:
java_test(
name = "mytest",
srcs = glob(["*.java"]),
main_class = "com.test.Test",
use_testrunner = 1,
)
RELNOTES: java_tests no complain when use_testrunner is explicitly set to 1 and main_class is set.
PiperOrigin-RevId: 177517757
|
|
|
|
|
|
|
| |
This will enable an easier transition from checked-in BUILD files to ones generated by copybara.
RELNOTES: None
PiperOrigin-RevId: 177514519
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ThinLTO and static linking of test suites is a bad combination since it results in a combinatorial explosion of the ThinLTO backends - each object file needs a separate LTO backend action per target. If you are static linking O(N) objects, and have O(M) targets, with ThinLTO you will get O(N*M) LTO backend jobs. This is because the whole program optimization step is per-target, and may make different decisions affecting the object files. With dynamic linking it isn't a problem, since the ThinLTO optimization happens at the .so level, which are shared across tests. And for statically-linked cc_binary it hasn't been an issue since typically only a single target is built at a time, unlike tests.
In general it isn't incredibly useful to run tests with ThinLTO, although most projects are in the habit of running their tests with the same options that they use to optimize their main binary (and most blueprints seem to be set up to share options between them). With ThinLTO since it is doing whole-program optimization, you are getting different whole-program optimizations for the main binary and each test binary, so it isn't the case that this will optimize the tests in the same exact way as the main binary anyway.
Therefore, when creating LTO backends for statically-linked *_test targets, skip the LTO indexing stage, and create (or use if already created) shared dummy LTO backend actions for each library. These LTO backends are fed an empty index, so they don't do any whole program optimization and are safe to share.
Enable this under a new feature so that we can enable it by default via blazerc but provide a facility to disable if needed.
RELNOTES: None
PiperOrigin-RevId: 177495858
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 177487913
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the FileSystem class to include the hash function as an
instance field. This allows us to have a different hash function
per FileSystem and removes technical debt, as currently that's
somewhat accomplished by a horrible hack that has a static method
to set the hash function for all FileSystem instances.
The FileSystem's default hash function remains MD5.
RELNOTES: None
PiperOrigin-RevId: 177479772
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 177476726
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 177460834
|
|
|
|
| |
PiperOrigin-RevId: 177459771
|
|
|
|
| |
PiperOrigin-RevId: 177452571
|
|
|
|
| |
PiperOrigin-RevId: 177447905
|
|
|
|
|
|
|
|
|
|
| |
Bazel should display the root cause of a test failure to the user. For
example, if a test could not be executed on a remote executor due to
there being no network connection, then it shouldn't display the test
as failed but tell the user about the network error.
RELNOTES:
PiperOrigin-RevId: 177439578
|
|
|
|
|
|
|
| |
Debug messages (generated with Skylark's `print` function) used to be filtered out by the output filter: if such messages are generated during the analysis phase in a package different to the target package (e.g. if a user builds //foo:foo and the message is generated in a dependency //bar:bar), the message are not shown by default, which makes an erroneous impression that the code for //bar:bar hasn't been executed at all and interferes with debugging. Now the output filter doesn't affect debug messages at all.
RELNOTES: Debug messages generated by `print()` are not being filtered out by --output_filter anymore, it's recommended not to use them in production code.
PiperOrigin-RevId: 177431255
|
|
|
|
|
|
|
|
|
| |
everywhere instead of duplicating process-wrapper --shell_arguments in Blaze.
To avoid a cyclic dependency, I broke up exec/local:local into exec/local:local and exec/local:options.
RELNOTES: None.
PiperOrigin-RevId: 177419268
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 177414939
|
|
|
|
|
|
|
|
|
| |
Make variables are derived from toolchain.
This will allow c++ targets to use c++ Make variables once platforms are
activated without declaring an explicit dependency on the c++ toolchain.
PiperOrigin-RevId: 177365568
|
|
|
|
|
|
|
| |
This key context can be used by actions to share partial key computations, for instance when computing MD5s for nested sets.
RELNOTES: None
PiperOrigin-RevId: 177359607
|
|
|
|
|
|
|
| |
If the check is useful, it can be done in the linter.
RELNOTES: None.
PiperOrigin-RevId: 177342483
|
|
|
|
| |
PiperOrigin-RevId: 177339358
|
|
|
|
|
|
| |
deps from a compressed GroupedList without uncompressing it. Also some minor GC improvements.
PiperOrigin-RevId: 177338852
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 177337384
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 177332323
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 177326265
|
|
|
|
|
|
| |
more logically belongs with other c++ rule types.
PiperOrigin-RevId: 177313718
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and expose transitive source jars to Skylark.
Initial change was rolled back (unknown commit). java_common.compile wouldn't fill the JavaRuleOutputJarsProvider when there was only one input source jar. Fixed that and added test (there was one before, but didn't check this particular provider).
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: 177311138
|
|
|
|
|
|
| |
It'd be nice to go further and break out a bunch of this code into more generally useful places (especially for callers that don't care about aspects). But that's a big mess and beyond the scope of what I'm aiming for here.
PiperOrigin-RevId: 177307854
|
|
|
|
|
|
|
|
| |
- Support custom ancestors and rule implementations.
- Refactor defaults into MockRuleDefaults.
- More thorough documentation.
PiperOrigin-RevId: 177303642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interconnected with 'main_class' in java_test rule.
for manual testing I used BUILD file:
java_test(
name = "mytest",
srcs = glob(["*.java"]),
main_class = "com.test.Test",
use_testrunner = 1,
)
RELNOTES: java_tests no complain when use_testrunner is explicitly set to 1 and main_class is set.
PiperOrigin-RevId: 177291746
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 177290508
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- remove BaseSpawn.Local; instead, all callers pass in the full set of
execution requirements they want to set
- disable caching and sandboxing for the symlink tree action - it does not
declare outputs, so it can't be cached or sandboxed (fixes #4041)
- centralize the existing execution requirements in the ExecutionRequirements
class
- centralize checking for execution requirements in the Spawn class
(it's possible that we may need a more decentralized, extensible design in
the future, but for now having them in a single place is simple and
effective)
- update the documentation
- forward the relevant tags to execution requirements in TargetUtils (progress
on #3960)
- this also contributes to #4153
PiperOrigin-RevId: 177288598
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of assuming BUILD.
- Default the list to the same value as PackageLookupFunction:
BUILD.bazel, BUILD.
- Move BuildFileNames to the packages package, so it is more generally
available.
Part of #4056.
Change-Id: Ie12512b492cd7d47a9e56ec3bc209f829feaf4b5
PiperOrigin-RevId: 177261295
|
|
|
|
|
|
|
|
|
|
|
| |
and #getDynamicLinkOptions to CppHelper. This allows toolchain information
needed by those methods to move to CcToolchainProvider.
The migration of toolchain information from CppConfiguration to
CcToolchainProvider is required to move the c++ rules to platform-based
toolchain selection.
PiperOrigin-RevId: 177230635
|
|
|
|
|
|
|
|
|
| |
Infer those values from STATIC_FRAMEWORK_FILE.
This correctly dedupes static frameworks between an app and its dylibs.
RELNOTES: None.
PiperOrigin-RevId: 177214770
|
|
|
|
|
|
|
| |
Update the docs for clarity and to explain the --expand_configs_in_place alternate expansion behavior.
RELNOTES: None.
PiperOrigin-RevId: 177183524
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Tickles the shell integration test version of b/35042288
*** Original change description ***
Change BlacklistedPackagesPrefixesFunction to take a pair of a hardcoded set 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: 177176068
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 177169878
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
SIPUSH and *CONST_*.
RELNOTES: None
PiperOrigin-RevId: 177149410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|