| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 190434178
|
|
|
|
|
|
|
| |
This mimics "--nodirect_run". Apparently, a lot of people depend on this :(
RELNOTES: None.
PiperOrigin-RevId: 190433808
|
|
|
|
|
|
|
|
| |
If a test target is built and testing is requested, nevertheless report what
was built.
Change-Id: Ida25f5f73fd4b5e102f2f4923acc555088495a8a
PiperOrigin-RevId: 190431506
|
|
|
|
|
|
|
|
|
| |
overwrite the environment of their caller.
Admittedly, doing that was a bad idea in the first place.
RELNOTES: None.
PiperOrigin-RevId: 190430189
|
|
|
|
| |
PiperOrigin-RevId: 190392567
|
|
|
|
|
|
| |
we're getting spurious analysis errors, helps to reduce noise.
PiperOrigin-RevId: 190355369
|
|
|
|
| |
PiperOrigin-RevId: 190349968
|
|
|
|
|
|
| |
$LazyLangPluginFlag.
PiperOrigin-RevId: 190349246
|
|
|
|
| |
PiperOrigin-RevId: 190348986
|
|
|
|
|
|
| |
better, get rid of it, and immutableSetMarshaller for good measure.
PiperOrigin-RevId: 190294922
|
|
|
|
| |
PiperOrigin-RevId: 190293560
|
|
|
|
|
|
| |
using Strategy.AUTO_VALUE_BUILDER, and filter out #toBuilder()-type methods when collecting getters of class.
PiperOrigin-RevId: 190292033
|
|
|
|
|
|
|
| |
To replace blaze_util::die and blaze_util::pdie as well, FATAL statements need to accept blaze exit codes.
RELNOTES: None.
PiperOrigin-RevId: 190285798
|
|
|
|
| |
PiperOrigin-RevId: 190285465
|
|
|
|
| |
PiperOrigin-RevId: 190285424
|
|
|
|
| |
PiperOrigin-RevId: 190284631
|
|
|
|
|
|
| |
in either a FULL or LITE version. Trigger new output with the new --transitions cquery flag in the new CqueryOptions class.
PiperOrigin-RevId: 190278664
|
|
|
|
| |
PiperOrigin-RevId: 190277450
|
|
|
|
| |
PiperOrigin-RevId: 190258675
|
|
|
|
|
|
|
|
| |
part of primary codepath somewhere around https://github.com/bazelbuild/bazel/commit/bde43ec8a96a62b8fbf67ad60d5154cf121647d9 (and killed entirely in unknown commit.
Force copying of a ByteString read from CodedInputStream in NestedSetCodec and persisted, since otherwise we might hang onto the entire buffer indefinitely.
PiperOrigin-RevId: 190256337
|
|
|
|
|
|
| |
If inlining is off, fixes a bug where null return values resulted in an error.
PiperOrigin-RevId: 190255818
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 190253911
|
|
|
|
|
|
|
|
|
|
|
| |
The number of *unique* Class instances that will be used as keys in these caches over the lifetime of a Bazel server is small-ish, and bounded by the size of the set of unique Classes used as the Java runtime representation of Skylark objects.
The bookkeeping done by LocalCache when the cache's size is bounded is therefore pure CPU overhead.
While we're here, just use the default capacity (16); a smaller initial capacity seems silly considering these caches are live for the duration of the Bazel server.
RELNOTES: None
PiperOrigin-RevId: 190238099
|
|
|
|
|
|
|
|
|
|
|
| |
BazelPackageBuilderHelperForTesting#sanityCheckBazelPackageLoader.
I should have written this comment more precisely. I am sorry I didn't. I vaguely recall some issues where the PackageFactory usage would do some scan of all the skylark classes and do some mutation to global state (this wouldn't normally be a problem since for blaze/bazel, there's one PackageFactory instance created per blaze/bazel server, and it's created at the beginning of the server).
Nevertheless, I do not see any problems now.
RELNOTES: None
PiperOrigin-RevId: 190229913
|
|
|
|
| |
PiperOrigin-RevId: 190224987
|
|
|
|
|
|
|
|
|
| |
work done by BazelPackageBuilderHelperForTesting#sanityCheckBazelPackageLoader.
We fix this flakiness by _not_ having RepositoryDelegatorFunction unconditionally 'fetch' local repos. We then have to make a change to BazelPackageLoader test to reinstate these mutations, since it was only working before due to the unconditional filesystem mutations done here :p
RELNOTES: None
PiperOrigin-RevId: 190222830
|
|
|
|
|
|
|
| |
third_party/gtest can go away after this.
RELNOTES: None.
PiperOrigin-RevId: 190221581
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Remove Optional<> where it's not needed. It's nice for return values, but IMHO it was overused in this code (e.g. Optional<List<X>> is an anti-pattern, as the list itself can already signal that it is empty).
- Use Bazel's own Path class when dealing with paths, not String or java.io.File.
- Move LinuxSandboxUtil into the "sandbox" package.
- Remove dead code and unused fields.
- Migrate deprecated VFS method calls to their replacements.
- Fix a bug in ExecutionStatistics where a FileInputStream was not closed.
Closes #4868.
PiperOrigin-RevId: 190217476
|
|
|
|
|
|
|
|
|
|
| |
- fix negatives + prefixes
- fix boundary cases (min int value)
The only remaining relevant differences from Python are that we disallow int() with zero args, we don't allow whitespace in strings, and we take Python 3's view on prohibiting leading 0s when base is 0.
RELNOTES: None
PiperOrigin-RevId: 190216646
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #4781.
Fix https://github.com/bazelbuild/bazel/issues/4149
RELNOTES:
Users can now pass --experimental_shortened_obj_file_path=true to have a shorter object file path, the object file paths (and all other related paths) will be constructed as following:
If there's no two or more source files with the same base name:
<bazel-bin>/<target_package_path>/_objs/<target_name>/<source_base_name>.<extension>
otherwise:
<bazel-bin>/<target_package_path>/_objs/<target_name>/N/<source_base_name>.<extension>
N = the file?s order among the source files with the same basename, starts from 0.
Examples:
1. Output names for ["lib1/foo.cc", "lib2/bar.cc"] are ["foo", "bar"]
2. Output names for ["foo.cc", "bar.cc", "foo.cpp", "lib/foo.cc"] are
["0/foo", "bar", "1/foo", "2/foo"]
The default value of --experimental_shortened_obj_file_path option is false, but we plan to flip it to true and eventually remove this option.
You shouldn't depend on the format of generated object file path, but if you do and this change breaks you, please use --experimental_shortened_obj_file_path=false to work around it.
PiperOrigin-RevId: 190214375
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 190207183
|
|
|
|
|
|
|
| |
DirectTargetProvider works with WalkableGraph directly. If it fails to find target, then last try to use delegate TargetProvider which supposed to be PackageManager from SkyframeExecutor.
RELNOTES:none
PiperOrigin-RevId: 190204106
|
|
|
|
| |
PiperOrigin-RevId: 190200144
|
|
|
|
|
|
|
| |
vardef().
RELNOTES: None.
PiperOrigin-RevId: 190196933
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 190196203
|
|
|
|
|
|
|
|
|
|
| |
The product name was previously propagated to all sandboxed spawn runners
unconditionally, even when the majority did not need it. Also, these
same spawn runners had obsolete constructors that were not used at all or
were only used in tests. Remove both for simplicity.
RELNOTES: None.
PiperOrigin-RevId: 190195305
|
|
|
|
|
|
|
| |
The only user of it was Android resource trimming, which just got deleted.
RELNOTES: None.
PiperOrigin-RevId: 190193627
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 190154101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This only modifies the DarwinSandboxedSpawnRunner for now and leaves behind
the Linux version.
The latter is a bit more complex to do because of the need to deal with tmpfs
and bind-mount interactions. We expect sandboxfs to have the biggest impact
on macOS anyway, not Linux, so this can wait until this has proven that it
deserves staying for the long-term.
Tested: Manually ran a self-build of Bazel on a version of Bazel built with
these changes and the build passed.
RELNOTES: None.
PiperOrigin-RevId: 190133429
|
|
|
|
|
|
|
| |
no issues of Skyframe-native in production.
RELNOTES: None
PiperOrigin-RevId: 190129810
|
|
|
|
|
|
|
| |
@SkylarkSignature
RELNOTES: None.
PiperOrigin-RevId: 190129404
|
|
|
|
|
|
|
|
|
| |
contains before invoking the heavier add. This reduces cpu-work and contention.
When blaze is invoked on a large fileset and the build is already up-to-date,
this makes things about 1.9s (33%) faster.
PiperOrigin-RevId: 190125803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AndroidManifest represents a new class to handle decoupled Android manifest
processing (as opposed to the existing ApplicationManifest, which handles
manifests, resources, and assets all together). This new manifest processing
pipeline will be used by the Skylark Android Data API.
AndroidManifest wraps the manifest and related information, so we don't just
pass around untyped Artifacts all the time. Additionally, the
StampedAndroidManifest subclass explicitly states that a manifest has been
stamped with the correct package (previous confusion between passing around the
stamped and unstamped manifests has led to bugs in Blaze).
Unlike the old manifest processing pipeline, AndroidManifest:
- Does not support the old legacy manifest merger
- Is decoupled from resource and asset processing
- Does incremental merges
- Always has the package defined at analysis time
- Can be run without an input manifest (for rules which don't specify their own
manifest but either inherit manifests that should be merged or to provide a
dummy manifest for tooling)
RELNOTES: none
PiperOrigin-RevId: 190119992
|
|
|
|
|
|
| |
Skyframe, rather than the potentially mutable builder, and @AutoCodec SkylarkAttr.Descriptor.
PiperOrigin-RevId: 190118565
|
|
|
|
|
|
| |
from the provided defaults in Options classes. These are used to create BuildOptionsDiffForReconstruction, which lets us store only the diffs in our BuildConfigurationValue.Keys.
PiperOrigin-RevId: 190117455
|
|
|
|
|
|
|
|
|
| |
This is the only difference in action implementation required for the new Skylark Android Data API design. Even if rules have resources or assets, after this API is adopted, they will no longer have to specify a primary manifest. Instead, a dummy manifest will be generated (either to merge with dependency manifests, or for use by IDEs if there are no dependency manifests).
Support this in the ManifestMergerAction by supporting not having a --manifest value passed.
RELNOTES: None
PiperOrigin-RevId: 190095623
|
|
|
|
|
|
| |
This avoids redundancy in memory when multiple NestedSets share a member
PiperOrigin-RevId: 190085907
|
|
|
|
|
|
|
|
|
|
|
| |
specifically get a semantics object
This is slightly redundant with useEnvironment, yes (as one can easily obtain the semantics object with Environment), but we intend on restricting useEnvironment so that structField=true methods cannot specify useEnvironment, but *can* specify useSkylarkSemantics.
In general, we can also ween off non structField methods to use useSkylarkSemantics instead of useEnvironment in cases where this is feasible.
RELNOTES: None.
PiperOrigin-RevId: 190082547
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 190079798
|
|
|
|
|
|
|
|
|
| |
This provider is the first part of the Skylark Android Data API.
This provider is not yet used by the native android_* rules, and is subject to change if needed to implement the rest of the Skylark Android data API.
RELNOTES: none
PiperOrigin-RevId: 190078860
|