| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are a bunch of reasons this shouldn't be exposed:
- ResourceContainer is a glob of several unrelated bits of functionality
- We are working on getting rid of ResourceContainer in favor of things like
AndroidResources
- We should pass information between targets using providers, not internal
state like ResourceContainer
RELNOTES: none
PiperOrigin-RevId: 195704044
|
|
|
|
|
|
|
| |
This collapsing should be avoided when possible, and punted on until execution when needed.
RELNOTES: none
PiperOrigin-RevId: 195695290
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the R.class to the provider, but keep it nullable in case no
resource/manifest attributes were specified, in which case the R.class would
not be generated.
A previous change tried to actually generate it in that case, but even though I
think that's probably the right strategy for the long term, it's substantially
different behavior and out of scope of this migration.
RELNOTES: none
PiperOrigin-RevId: 195682271
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
execution on Windows from Java launcher.
Previously the test case would fail because it tried to run a path like this:
C:/temp/build-1dad9dd4-ee96-40c5-b551-c8ae12461e45/bazel-out/x64_windows-fastbuild/bin/foo/foo_test.exe.runfiles/C:/openjdk/bin/java.exe
Passing presubmit: https://buildkite.com/bazel/google-bazel-presubmit/builds/2558#b83dbc25-d9ad-4d49-8f78-cde9d6810741
RELNOTES: N/A
PiperOrigin-RevId: 195675424
|
|
|
|
|
|
|
|
|
| |
Staticness is confusing, I always have to investigate which is Staticness and
which is LinkStaticness, and even in isolation staticness is not a great name. I
believe LinkerOrArchiver is a better name :)
RELNOTES: None.
PiperOrigin-RevId: 195674810
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 195664306
|
|
|
|
|
|
|
| |
Closes #4628
Closes #5155.
PiperOrigin-RevId: 195662967
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 195659799
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Memory regression (b/79331026)
*** Original change description ***
Some fixup for R.class files
Expose R.class file in AndroidResourcesInfo, to allow Java compilation.
Include documentation that the R.class should not be used in other targets.
Actually generate the R.class file in the case of an android_library with no
manifest, resources, or assets, rather than compiling it from the R.java
RELNOTES: none
PiperOrigin-RevId: 195659672
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, introduce caching for duplicated qualifiers.
Rolling Forward:
Fixed attempting to parse non-resource directories with dashes as resource directories.
Added test for this case.
RELNOTES: None
PiperOrigin-RevId: 195658978
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 195658252
|
|
|
|
|
|
|
| |
To handle a common debugging workflow where you want to pause
execution of one/all threads.
PiperOrigin-RevId: 195657472
|
|
|
|
|
|
|
| |
There are still a few global @SkylarkSignature-annotated top-level objects that need to be migrated in SkylarkRuleClassFunctions, but this migrates everything else.
RELNOTES: None.
PiperOrigin-RevId: 195652038
|
|
|
|
|
|
|
| |
removal, but for the test.
RELNOTES: None
PiperOrigin-RevId: 195651521
|
|
|
|
|
|
|
| |
Since configuration fragments will extend from build API classes, @SkylarkConfigurationField no longer needs to annotate a method defined on a @SkylarkModule class. Ideally, we would ensure that a configuration fragment with a @SkylarkConfigurationField method implements an interface with @SkylarkModule, but this seems impossible to perform at the level of an annotation processor.
RELNOTES: None.
PiperOrigin-RevId: 195651344
|
|
|
|
|
|
|
|
| |
Only the last commit needs to be reviewed, as it's rebased on https://github.com/bazelbuild/bazel/pull/5101
Closes #5117.
PiperOrigin-RevId: 195649921
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
directory structures.
When building a parent node from action inputs, the paths to the files are
sorted. These paths are then broken down into segments and a tree structure
is created from the segments.
Problem is, the segments at each level of the tree structure are not sorted
before they are added to the parent node. This can result in an unordered
directory tree.
For example, the sort order of this list of files
```
/foo/bar-client/bar-client_ijar.jar
/foo/bar/bar_ijar.jar
```
is maintained when it becomes a tree structure
```
foo ->
bar-client ->
bar-client_ijar.jar
bar
bar_ijar.jar
```
which is out of order.
Resolves: #5109
Closes #5110.
PiperOrigin-RevId: 195649710
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 195586974
|
|
|
|
|
| |
RELNOTES: none.
PiperOrigin-RevId: 195497740
|
|
|
|
| |
PiperOrigin-RevId: 195486836
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 195486038
|
|
|
|
|
|
|
|
|
| |
Mostly this is removing a needless restriction on proto_library to have java_api_version and j2objc_api_version set. The rest was already working.
Tons of tests had to be updated.
RELNOTES: None
PiperOrigin-RevId: 195450685
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 195428899
|
|
|
|
|
|
|
|
|
|
|
| |
We allow repository rules to return a reproducible version of themselves,
or a list of fully reproducible rules they expand to. Add a module collecting
all those answers, logging them at each invocation, if requested; this
collection can also be used by the upcoming 'sync' command to generate
a WORKSPACE.resolved file.
Change-Id: Iac1358de1b74633810d300ba2bf45bba8b3992dc
PiperOrigin-RevId: 195427096
|
|
|
|
|
|
|
| |
CcToolchainFeatureSelection class
RELNOTES: None.
PiperOrigin-RevId: 195425336
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 195422399
|
|
|
|
|
|
|
|
|
|
|
| |
- add 'start debugging' request/response messages. The debug server will
block until this request is received, allowing the client to perform
initial setup (e.g. setting breakpoints)
- support conditional breakpoints
- add a column index to the Location message
- rename 'line number' to 'line index', and specify that it's 0-based
PiperOrigin-RevId: 195420363
|
|
|
|
|
|
|
|
|
|
|
|
| |
Expose R.class file in AndroidResourcesInfo, to allow Java compilation.
Include documentation that the R.class should not be used in other targets.
Actually generate the R.class file in the case of an android_library with no
manifest, resources, or assets, rather than compiling it from the R.java
RELNOTES: none
PiperOrigin-RevId: 195419781
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaks a few thousands targets
*** Original change description ***
Remove fully static linking part of ctx.fragments.cpp.fully_static_link_options
Since we always pass true as argument (meaning it's for dynamic library), we
don't need the part for executable. And we don't want more users of this method,
therefore removing.
RELNOTES: None.
PiperOrigin-RevId: 195411765
|
|
|
|
|
|
|
|
|
|
|
|
| |
This effectively subsumes all existing memory estimation, as it no
longer matters too much how much memory is assigned to each action.
WIP: This is a hack, and if it goes in, should almost certainly be
hidden behind a configuration option.
Closes #4938.
PiperOrigin-RevId: 195378568
|
|
|
|
| |
PiperOrigin-RevId: 195321054
|
|
|
|
| |
PiperOrigin-RevId: 195316047
|
|
|
|
|
|
|
| |
Also, introduce caching for duplicated qualifiers.
RELNOTES:None
PiperOrigin-RevId: 195313195
|
|
|
|
|
|
|
| |
This prevents subsequent generations of documentation reordering categories
RELNOTES: None.
PiperOrigin-RevId: 195310737
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 195296176
|
|
|
|
|
|
|
|
|
| |
request the Package for that Label, and in that way materialize the Rule.
Rule instances (which have a reference back to their Package) should not be in
SkyKeys, since they are large and slow down serialization.
PiperOrigin-RevId: 195294804
|
|
|
|
|
|
| |
backend writes for inner NestedSet serialization.
PiperOrigin-RevId: 195294676
|
|
|
|
|
|
|
|
|
|
| |
Looks like migration from standalone MavenDownloader to one based on HttpDownloader kept state-setting, but made MavenDownloader a singleton, creating a race.
I'm about 99% sure this fixes #5103. The bug is in the right place, and running the test case described in that issue 25 times in a loop produced no errors.
Closes #5121.
PiperOrigin-RevId: 195289232
|
|
|
|
|
|
|
|
|
| |
This gets it out of the AndroidLibrary code. Everything ends up cleaner, plus
it'll be easier to call into this code from a method exposed to Skylark (next
review).
RELNOTES: none
PiperOrigin-RevId: 195289199
|
| |
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 195280015
|
|
|
|
|
|
| |
abstract class. This is also helpful for the new recursive package provider I'll be adding to support recursive patterns in cquery.
PiperOrigin-RevId: 195279920
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 195279335
|
|
|
|
|
|
|
|
|
| |
Since we always pass true as argument (meaning it's for dynamic library), we
don't need the part for executable. And we don't want more users of this method,
therefore removing.
RELNOTES: None.
PiperOrigin-RevId: 195276402
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 195274968
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 195266230
|
|
|
|
|
|
|
|
| |
Since we want to expose creation of compile build variables to Skylark, it's
better if we don't pass provider into the construction, but plain data.
RELNOTES: None.
PiperOrigin-RevId: 195265117
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 195264146
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is mostly a roll-forward of 4465dae23de989f1452e93d0a88ac2a289103dd9, which
was reverted by fa36d2f48965b127e8fd397348d16e991135bfb6. The main difference is
that the new behavior is now gated behind the --noremote_allow_symlink_upload
flag.
https://docs.google.com/document/d/1gnOYszitgrLVet3sQk-TKGqIcpkkDsc6aw-izoo-d64
is a design proposal to support symlinks in the remote cache, which would render
this change moot. I'd like to be able to prevent incorrect cache behavior until
that change is implemented, though.
This fixes https://github.com/bazelbuild/bazel/issues/4840 (again).
Closes #5122.
Change-Id: I2136cfe82c2e1a8a9f5856e12a37d42cabd0e299
PiperOrigin-RevId: 195261827
|
|
|
|
|
|
|
|
| |
Different places in the link logic were in charge of expanding start/end lib archives, causing discrepancies. This CL gets rid of the special iteration in Link.java and makes LibrariesToLinkCollecter solely responsible for mapping static libraries to their object files on the link command l...
RELNOTES:
Fixing start/end lib expansion for linking. There were many cases where archive files were still being used with toolchains that support start/end lib. This change consolidates the places that make that decision so they can be more consistent.
PiperOrigin-RevId: 195258075
|