| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
(Almost) all native declared providers are accessed as such and not as
native non-declared providers (inheritors of TransitiveInfoCollaction).
There are still three providers that use
TransitiveInfoCollection.WithLegacySkylarkName mechanism, I'll address
them in the follow-up CL.
RELNOTES: None.
PiperOrigin-RevId: 161655315
|
|
|
|
|
|
|
|
|
| |
set USE_MSVC_WRAPPER=1 if you still want to use wrapper script.
RELNOTES:
Windows: Wrapper-less CROSSTOOL becomes default now.
set USE_MSVC_WRAPPER=1 if you still want to use wrapper script.
PiperOrigin-RevId: 161654018
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- --experimental_strict_action_env makes Bazel not forward PATH,
LD_LIBRARY_PATH, and TMPDIR to all actions. This is intended to be a
transitional flag; as part of rollout, we'll need to update all users that
rely on the current behavior to specify their needs explicitly (with
--action_env). But note that action_env is not yet applied to all actions,
which also needs to be fixed.
- --shell_executable can be used to explicitly set the shell executable to
use in actions. On Windows, if --experimental_strict_action_env is unset,
then the PATH is computed to include the path to the shell executable.
Progress on #2574.
PiperOrigin-RevId: 161652996
|
|
|
|
|
|
|
|
| |
The method is moved to FeaturePolicyConfiguration.java so that it can be used
by unrelated parts of the code using feature policies for whitelisting.
RELNOTES:none
PiperOrigin-RevId: 161648169
|
|
|
|
|
|
|
|
|
|
| |
The existing support for including a flat list of labels was moved to the `srcs` attribute.
See https://github.com/bazelbuild/bazel/issues/3317 for context and motivation.
Closes #3318.
PiperOrigin-RevId: 161645944
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Make use of existing abstractions like SpawnRunner and SpawnExecutionPolicy.
- Instead of having the *Strategy create a *Runner, and then call back into
SandboxStrategy, create a single SandboxContainer which contains the full
command line, environment, and everything needed to create and delete the
sandbox directory.
- Do all the work in SandboxStrategy, including creation and deletion of the
sandbox directory.
- Use SpawnResult instead of throwing, catching, and rethrowing.
- Simplify the control flow a bit.
PiperOrigin-RevId: 161644979
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sameBlobsShouldNotBeUploadedTwice() test was found flaky on bazel ci
[1]. This can happen when the first upload finishes before the second is
started.
Add a CountDownLatch to stop the first upload from completing, before the
second is started.
[1] https://github.com/bazelbuild/bazel/issues/3348
PiperOrigin-RevId: 161641110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove the Chunker.Builder and use the Chunker constructors instead.
- Fix a correctness bug, where the chunker would ignore the return value
of InputStream.read(byte[]).
- Have Chunk.getData() return a ByteString as opposed to a byte[]. All
callsides need ByteString objects and this change makes the subsequent
change possible.
- Have the Chunker use a preallocated byte[] in order to avoid
allocating a new one on every call to next().
RELNOTES: None.
PiperOrigin-RevId: 161637158
|
|
|
|
|
| |
Change-Id: Iaaf3272f45cce04d41e75ffbe2fa5b5b9f68734c
RELNOTES: None.
|
|
|
|
| |
Change-Id: I8b0f4e7547358704d038db312795c58acaaac4a7
|
|
|
|
|
|
|
|
| |
And instead rely on the flags being set in java_toolchain.jvm_opts.
This change is being made in preparation for JDK 9, which replaces
-Xbootclasspath/p with --patch-module.
PiperOrigin-RevId: 161620182
|
|
|
|
|
|
|
|
|
|
| |
As far as I can tell this is largely equivalent to the current behaviour:
* Instead of discovering inputs in ExtraAction and adding its own runfiles supplier, just pass the composite one in the first place and let the normal thing happen
* The mnemonic returned by the override seems to be equivalent to the one from the extra action anyway, which is what the base class does
* The extra action key will change slightly as it will now include the composite runfiles supplier, but I can't see how that would be a problem.
PiperOrigin-RevId: 161608100
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 161588977
|
|
|
|
| |
PiperOrigin-RevId: 161582236
|
|
|
|
|
|
| |
RELNOTES: none
TESTED=remote worker
PiperOrigin-RevId: 161572597
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Broke the go rules (of course)
See http://ci.bazel.io/job/rules_go/BAZEL_VERSION=HEAD,PLATFORM_NAME=linux-x86_64/1044/console.
*** Original change description ***
Resolve references to @main-repo//foo to //foo
Bazel was creating an dummy external repository for @main-repo, which
doesn't work with package paths and will cause conflicts once
@main-repo//foo and //foo refer to the same path.
This adds a "soft pull" option to WorkspaceNameFunction: it can either
parse the entire WORKSPACE file to find the name or just the first section.
That way PackageLookupFunction can find the repository name without causing
a circular dependency.
This should have no ch...
***
PiperOrigin-RevId: 161572272
|
| |
|
|
|
|
|
|
|
| |
Found by searching for TODOs mentioning "Java 7". There are plenty of other instances where we can simplify, but I don't want to be responsible for a large blast radius. At least in these cases we're fixing outdated comments.
RELNOTES: None
PiperOrigin-RevId: 161570189
|
|
|
|
|
|
| |
*** Reason for rollback ***
PiperOrigin-RevId: 161567104
|
|
|
|
| |
PiperOrigin-RevId: 161563102
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 161560683
|
|
|
|
|
| |
RELNOTES: Remove apple_watch1_extension and apple_watch_extension_binary rules. Users should be using the skylark watchos_application and watchos_extension rules. https://github.com/bazelbuild/rules_apple has details.
PiperOrigin-RevId: 161555395
|
|
|
|
|
|
|
|
|
| |
- changed field names and a couple accessors to consistently use full words ("statement" instead of "stmt")
- applied several local analyzers (from IntelliJ) to remove redundant modifiers, unnecessary explicit types (yay Java 8), etc.
RELNOTES: None
PiperOrigin-RevId: 161551096
|
|
|
|
|
|
|
|
| |
Don't call the `toString` method on unknown objects as it potentially
breaks hermeticity and determinism. Use a generic string like
"<unknown object package.ClassName>" instead.
PiperOrigin-RevId: 161544828
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change ensures that the server process is terminated before the
client process terminates, when evaluating a command that shuts down
the server.
When completing such a command, the server communicates to the client
that the server will terminate itself by setting a termination_expected
bit in the final RunResponse message. The client then waits up to 60s
for the server process to actually terminate. If it does not, then the
client SIGKILLs the server.
Also makes the gRPC server stop accepting new commands before the
shutdown command completes.
Drive-by fix to comments on Search{Un,Null}aryOption.
RELNOTES: Commands that shut down the server (like "shutdown") now ensure that the server process has terminated before the client process terminates.
PiperOrigin-RevId: 161537480
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel was creating an dummy external repository for @main-repo, which
doesn't work with package paths and will cause conflicts once
@main-repo//foo and //foo refer to the same path.
This adds a "soft pull" option to WorkspaceNameFunction: it can either
parse the entire WORKSPACE file to find the name or just the first section.
That way PackageLookupFunction can find the repository name without causing
a circular dependency.
This should have no change of behavior and is already tested in
https://github.com/bazelbuild/bazel/blob/master/src/test/shell/bazel/workspace_test.sh#L176.
PiperOrigin-RevId: 161536466
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161535034
|
|
|
|
|
|
|
|
| |
This value can be passed in Skylark to java_common.compile#java_toolchain in
order to avoid incompatibility issues when the value of --java_toolchain uses a
different Java version.
PiperOrigin-RevId: 161528114
|
|
|
|
|
|
|
|
|
| |
to use.
Part of #2219.
Change-Id: Id6dfe6ec102f609bb19461242a098bf977be29ae
PiperOrigin-RevId: 161527986
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 161527470
|
|
|
|
|
|
|
|
|
| |
Skylark's Printer.BasePrinter doesn't guarantee it will call `.toString` on
objects of unknown types, and in the future that won't be the case anymore.
In order to keep their current string representations objects should implement
the SkylarkValue interface by providing an explicit implementation of `repr`.
PiperOrigin-RevId: 161526182
|
|
|
|
| |
PiperOrigin-RevId: 161523047
|
|
|
|
| |
PiperOrigin-RevId: 161521237
|
|
|
|
|
|
|
|
| |
The test now uses a fake clock and replaces calls to Thread.sleep() by manual
changes to the clock.
RELNOTES:none
PiperOrigin-RevId: 161520781
|
|
|
|
|
|
| |
generate_workspace tool.
PiperOrigin-RevId: 161520698
|
|
|
|
| |
PiperOrigin-RevId: 161520675
|
|
|
|
|
|
|
|
|
|
|
| |
can depend on the C++ toolchain/Java runtime being used.
The naive way to do this would be via @bazel_tools//, except that that does not take configuration transitions into account and e.g. will be the same in the host and the target configurations even if different toolchains are used.
Eventually, this will be supplanted by the toolchain selection mechanism. However, that is not live yet and the migration cost this will incur is not a lot; just replacing the one single instance of these undocumented rules with the reference to the toolchain type.
RELNOTES: None.
PiperOrigin-RevId: 161519229
|
|
|
|
|
|
|
|
| |
repository rules documentation links to 404
Closes #3341.
PiperOrigin-RevId: 161516419
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/3357
RELNOTES: none
PiperOrigin-RevId: 161516302
|
|
|
|
|
|
|
|
|
|
| |
OptionMetadataTags.
These are similar, no need to have both fields. Removing the "DOCUMENTED" default, the absence of UNDOCUMENTED will be used instead.
Since requiring a documentation category for undocumented options doesn't make sense, list that as one of the OptionDocumentationCategories, but list HIDDEN and INTERNAL as part of OptionMetadata. These options should list UNDOCUMENTED as their category.
PiperOrigin-RevId: 161515674
|
|
|
|
| |
PiperOrigin-RevId: 161512574
|
|
|
|
|
|
|
|
|
|
|
| |
From a BEP point of view, the only interface of a configuration we care
about is its BuildEvent structure. Represent it as such, so that we
can move this class to the rest of the buildeventstream module. This
is a prerequisite for ActionOwners refering to configurations in the
BEP.
Change-Id: I6d1c1bf2951aac91607e83cad664553cd6620df8
PiperOrigin-RevId: 161510049
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running locally, I noticed that the multipleBlobsUploadShouldWork() test
is flaky (~1% of all runs).
The flakiness exists due to Future.get() being notified about completion
before the future's listeners are executed. We make use of future
listeners to remove an upload digest from an internal hashmap, after the
upload completed. Thus, checking for this map to be empty immediately
after uploadBlob (aka Future.get()) returned, could sometimes fail due
to the listeners not having executed yet.
The fix is to periodically poll the hashmap until all listeners have
executed.
RELNOTES: None.
PiperOrigin-RevId: 161507486
|
|
|
|
| |
PiperOrigin-RevId: 161505952
|
|
|
|
|
|
|
| |
dependency.
RELNOTES: None.
PiperOrigin-RevId: 161504700
|
|
|
|
|
|
|
| |
Fixed https://github.com/bazelbuild/bazel/issues/3344#issuecomment-314167833
RELNOTES: None
PiperOrigin-RevId: 161500109
|
|
|
|
|
|
|
|
|
|
| |
Make sure that ZipEntry paths always use forward
slashes, even on Windows. Also add a test.
See https://github.com/bazelbuild/bazel/issues/3264
Change-Id: I4508e46dde49cd44c8e3792017d0d280a51dc565
PiperOrigin-RevId: 161500049
|
|
|
|
|
|
| |
The new implementation doesn't use the metadata jar anymore, but wraps all the uninstrumented classes in the build jar among with a txt file that contains the paths of the files to be instrumented.
PiperOrigin-RevId: 161499019
|
|
|
|
|
|
|
| |
This is necessary so that Make variables are not accessed from BuildConfiguration, which is in turn necessary so that we can forego package loading during configuration creation (currently we need to parse the java_runtime_suite / java_runtime rules to create the Jvm fragment)
RELNOTES: None.
PiperOrigin-RevId: 161496779
|
|
|
|
|
|
|
| |
That's the only way to provide sane behavior both in Skylark and in Java.
RELNOTES: None.
PiperOrigin-RevId: 161496153
|