| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 182033773
|
|
|
|
|
|
|
| |
Fixes #3234.
Change-Id: I1bfbe856d35b98995f5a0684fe47c7566b8dd093
PiperOrigin-RevId: 182029085
|
|
|
|
|
|
|
|
|
|
| |
Added tests for checking JavaSourceJarsProvider state.
All other providers will be implemented in next CLs.
previous CL with JavaCompilationArgsProvider implementation is https://github.com/bazelbuild/bazel/commit/32dff21d00ad7d1bdf50e8761d675a6e7e002de9
RELNOTES:none
PiperOrigin-RevId: 182028182
|
|
|
|
|
|
|
|
| |
This method violates the invariant that derived roots are never equal to the exec root. Only source roots can be equal to the exec root.
Note that this method was only used in tests, so this CL should be completely safe as long as its tests pass.
PiperOrigin-RevId: 181998483
|
|
|
|
|
|
| |
In this case, the invariant violated is creating derived roots at the exec root.
PiperOrigin-RevId: 181994080
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 181990193
|
|
|
|
| |
PiperOrigin-RevId: 181975994
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 181973847
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/4376
Change-Id: Id78bb0930044626304e54f07735db4d4b2c84720
PiperOrigin-RevId: 181959528
|
|
|
|
|
|
|
|
|
|
| |
Work towards #3676.
The behavior is still incorrect (we should in fact disallow this), but
at least there is no hard crash.
Change-Id: I5181dba73ad725d20b2ea82b2f19e86664b9dbff
PiperOrigin-RevId: 181954820
|
|
|
|
|
|
|
| |
Fixes #3836.
Change-Id: Icc9e8e08c4336fc20f46b6b878986b991d62ab18
PiperOrigin-RevId: 181949937
|
|
|
|
|
|
|
|
|
| |
Change-Id: Ib8dd9265b18fa0915f52427567845105fcdfa295
Closes #4447.
Change-Id: Ib8dd9265b18fa0915f52427567845105fcdfa295
PiperOrigin-RevId: 181943004
|
|
|
|
|
|
| |
https://github.com/bazelbuild/bazel/commit/3864a45afa368473a4a6a90d69edb48cb67d367a
PiperOrigin-RevId: 181940016
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
before: blaze build --nobuild //foo --experimental_post_build_query="deps(//foo)"
after: blaze cquery "deps(//foo)"
pros of ui change:
- more concise
- assumes query expression targets == targets to be built (but allows for flexibility through --top_level_targets flag)
- separate from build command
- cquery command recognizes query options, build options, and its own unique set of options
cons of ui change:
- adds another command to blaze
- recognizes options that don't actually work yet -> requires more option validation
RELNOTES: None
PiperOrigin-RevId: 181816980
|
|
|
|
|
|
|
|
|
| |
This avoids invalid layouts (non-sequential map values), and provides better separation between a layout's representation as a map and its view as a list.
Also removed a factory method that's unnecessary, now that the plan is not to closely tie SkylarkInfo to SkylarkProvider.
RELNOTES: None
PiperOrigin-RevId: 181807071
|
| |
|
|
|
|
| |
PiperOrigin-RevId: 181797078
|
|
|
|
|
|
|
|
|
|
| |
When checking for conflicts between an input and an output file
of a rule, honor the repository the label belongs to. It is a
perfectly valid use case to create one file from an equally named
(including path) in a different repository.
Change-Id: I3aaa99eaa0c473ec31c5cc77beacf657c41ef56d
PiperOrigin-RevId: 181761940
|
|
|
|
|
|
|
|
|
|
|
|
| |
The upcoming path refactor will normalize all path fragments upon creation. That is fine 99% of the time, but sometimes we want to disallow non-normalized paths on rule attributes. Even this isn't usually a problem since we can validate the string prior to putting it in a path fragment.
However, in the case of the packaging rule we do not know the rules of validation until the packaging rule is *consumed* by some other rule. Therefore, retain input as a string on these rules all the way through.
We don't really do a lot of path fragmenty stuff with these strings. The main drawback is losing a bit of type safety / readability.
SKIP_KOKORO
PiperOrigin-RevId: 181760613
|
|
|
|
|
|
| |
This is no longer used.
PiperOrigin-RevId: 181754475
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1.Deleted config_setting for --cpu=x64_windows_msys, because we don't build
Bazel with MSYS gcc anymore.
2.Deleted config_setting for --cpu=x64_windows_msvc, because it uses exactly
the same toolchain as --cpu=x64_windows, it'll be removed in the future.
This change reduces the complexity of our BUILD files and make them less
confusing.
Change-Id: I939831a6861413b0f745fb1be98aacd4fb780e0a
PiperOrigin-RevId: 181751853
|
|
|
|
| |
PiperOrigin-RevId: 181750466
|
|
|
|
|
|
|
|
|
| |
Also rename setLinkType() to setStaticLinkType() in CcLibraryHelper to make it clear that we are setting the specific linking type for the static library.
This is an improved version of https://github.com/bazelbuild/bazel/commit/a705eaa9225ff8a03975c8cb49faa6b2899e398d which was rolled back due to a previous conflicting CL causing problems in the nightly.
RELNOTES:none
PiperOrigin-RevId: 181746447
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/4421
RELNOTES: none
PiperOrigin-RevId: 181742216
|
|
|
|
|
|
|
| |
Most places handle them the same way as IOException, which seems like a safe
default. The places that do care can still throw or catch the more specific type.
PiperOrigin-RevId: 181719688
|
|
|
|
|
|
| |
This is a first-class artifact concept. No need to go the long way to get this path.
PiperOrigin-RevId: 181717016
|
|
|
|
|
|
| |
When there is no root directory this minimises the size of the change required to keep InMemoryFileSystem working.
PiperOrigin-RevId: 181685159
|
|
|
|
| |
PiperOrigin-RevId: 181684446
|
|
|
|
|
|
| |
heavyweight. For now, put a BuildConfigurationValue.Key in there. In the future, we may want to put some kind of "delta" key in.
PiperOrigin-RevId: 181673805
|
|
|
|
|
|
| |
They need this to parse input manifests. Previously we would grab the exec root from the Root, but wish to unsupport this.
PiperOrigin-RevId: 181669143
|
|
|
|
|
|
|
| |
This fixes a regression introduced by some prior refactoring work.
RELNOTES: None.
PiperOrigin-RevId: 181665047
|
|
|
|
|
|
| |
We don't need to construct roots to relativize a path.
PiperOrigin-RevId: 181661592
|
|
|
|
|
|
| |
removing the layer of indirection of getting SkyKey out of ActionLookupKey, which uses more memory for no reason.
PiperOrigin-RevId: 181658615
|
|
|
|
| |
PiperOrigin-RevId: 181657963
|
|
|
|
|
|
|
| |
Info objects no longer store a string pointer for their error message format, which is almost always the same as the one specified by their provider type. Only map-based SkylarkInfo used this (for fancy built-in structs like ctx.attr), so the field is pushed down to there.
RELNOTES: None
PiperOrigin-RevId: 181654641
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 181653922
|
|
|
|
|
|
| |
memory and some work: BuildOptions#equals and #hashCode already take that value into account, so pulling it out does nothing but slow us down during Key construction.
PiperOrigin-RevId: 181645301
|
|
|
|
|
|
| |
Windows doesn't have a root directory, so this abstraction doesn't make sense and should be removed.
PiperOrigin-RevId: 181638749
|
|
|
|
| |
PiperOrigin-RevId: 181638689
|
|
|
|
|
|
| |
It was put there to support "/" as the workspace. Checking for a null parent will do the same thing.
PiperOrigin-RevId: 181638375
|
|
|
|
| |
PiperOrigin-RevId: 181624201
|
|
|
|
|
|
|
|
|
| |
- Info now has one protected constructor. (Would've preferred the builder pattern, but inheritance makes it much more verbose.)
- Direct SkylarkInfo subclass access is replaced by factory methods and an isCompact() accessor.
- Added/simplified tests
RELNOTES: None
PiperOrigin-RevId: 181616757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
This was missing adding LTO files in the cc_embed_data rule.
Fixed and added test.
*** Original change description ***
Automated rollback of commit 67330ad52391ad6562d439f77cc5133a0ea4247d.
*** Reason for rollback ***
Breaks nightly: b/71790513
*** Original change description ***
C++ refactoring: Separate compilation and linking calls to CcLibraryHelper
RELNOTES:none
PiperOrigin-RevId: 181613477
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bazel now adds env[TMPDIR] to the set of
sandbox-writable paths, instead of adding the
caller-defined `tmpDir` as it used to.
Since every caller of getWritableDirs passes the
LocalEnvProvider-processed environment to
getWritableDirs, and because all such callers use
either PosixLocalEnvProvider or
XCodeLocalEnvProvider, we can be sure that the
environment has an entry for TMPDIR.
Change-Id: Ia89544a009e56d9cc922ab56823d16d20465545e
PiperOrigin-RevId: 181595606
|
|
|
|
|
|
|
| |
JavaConfiguration.
RELNOTES: None.
PiperOrigin-RevId: 181593727
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When Bazel creates the sandbox for an action,
Bazel collects a set of paths that the action may
write to.
The action needs write access to its temp
directory, so Bazel needs to add it to the
writable paths.
See https://github.com/bazelbuild/bazel/issues/4376
Change-Id: Ifd3c482aa67ff8a2070045356abad8b39c808db8
PiperOrigin-RevId: 181591520
|
|
|
|
|
|
|
|
|
|
|
|
| |
The BuildEventStreamer supports a method flush() to report any pending
stdout/stderr in the BEP; in particular, all internal buffers of for
those streams are cleared (and the memory can be reclaimed). If there
are no pending bytes in those streams, however, there is no need to
generate an additional progress event to get rid of the buffered stream
contents. Make flush() a no-op in this case.
Change-Id: Ia8cf8733fdeaf4d1a50488736d2637862e7cb4f5
PiperOrigin-RevId: 181590982
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 181579365
|
|
|
|
|
|
| |
RELNOTES: The --[no]experimental_disable_jvm command line option is not
supported anymore.
PiperOrigin-RevId: 181575259
|
|
|
|
|
|
|
|
|
|
| |
For different applications, different size of buffered stdout/stderr might be
acceptable; essentially it is a trade off between latency and number of messages
generated. Put this trade off into the control of the user by adding an appropriate
flag.
Change-Id: I8fb4d19a336205fa28d01340f2f0b2be9b4a24f3
PiperOrigin-RevId: 181570242
|