| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Partly addresses #374.
Specifically allow !%^`"'&;<>?[]{|} in target and package names. It's actually
simpler now to declare what we don't allow. In target names:
0-31 (control characters)
58 ':' (colon)
92 '\' (backslash)
127 (delete)
In package names:
0-31 (control characters)
58 ':' (colon)
64 '@' (at-sign)
92 '\' (backslash)
127 (delete)
- '\' is a path segment separator on Windows, and allowing it can lead to
silent output file conflicts and - therefore - data corruption. We may be
able to allow it in the future, but I didn't want to make that call.
- ':' is a special character that Bazel interprets as the package name / target
name separator.
- '@' in package names can probably be allowed; at the beginning of a label it
indicates a workspace name, but not within a segment. We actually have some
tests that disallow it specifically, but those can probably just be deleted;
however, it does require a bit of investigation, so I decided to delay that
change.
It is possible that we don't correctly escape filenames in all cases. Also note
that the shell may require escaping for specific characters, and that Bazel
treats a single '*' (star) target name specially when given on the command
line.
RELNOTES: Bazel now allows almost all 7-bit ASCII characters in labels.
PiperOrigin-RevId: 196650651
|
|
|
|
|
|
|
|
| |
Since cdc99afc1a03ff8fbbbae088d358b7c029e0d232 label arguments are
prefetched. So it is no longer necessary to access them early.
Change-Id: I6d30bae3ac655387641ffd98f9b9aa95d2f1ece7
PiperOrigin-RevId: 196632853
|
|
|
|
| |
Change-Id: I02b6384272de91dce3df5bbc56424338ba914e90
|
|
|
|
|
|
|
| |
This is in preparation for fixing env handling as well as cache key (to use
env) computations in subclasses of SpawnAction.
PiperOrigin-RevId: 196626495
|
|
|
|
|
|
| |
(3-8x faster than StringCodec).
PiperOrigin-RevId: 196615858
|
|
|
|
|
|
|
|
|
| |
Use update() and other methods which properly respect the trimming
transition over those which don't. Avoid using the target configuration
if the configuration actually used by a target is available.
RELNOTES: None.
PiperOrigin-RevId: 196588405
|
|
|
|
|
|
|
|
| |
The local JDK is now the default --javabase and needs to be available for these
tests, see:
https://github.com/bazelbuild/bazel/commit/849df36c5ad31ebe8791c4228321c38c6d0ae56c
PiperOrigin-RevId: 196575260
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Caused a memory regression
*** Original change description ***
Expose cc_common.create_compile_build_variables
This cl enabled skylark rules to create build variables used for C++ compile
actions (in a limited form, e.g. build variables for modules are not exposed
etc).
Working towards #4571.
RELNOTES: None
PiperOrigin-RevId: 196566686
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196561473
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 196553226
|
|
|
|
|
|
|
|
| |
BuildOptions$DiffForReconstruction serializations are reached in this way, so we get better efficiency. Also, it was already a custom codec, so less new handrolling.
Also use serialization framework for FragmentClassSet, instead of doing serialization directly. Default FragmentClassSet should be a constant, so it will serialize down to a byte or three. Future changes can make all the classes constants as well, if we're getting misses on them.
PiperOrigin-RevId: 196546279
|
|
|
|
|
|
|
| |
It is a left over from long ago, and nothing should be using it as the
swift support is now via skylark rules and no longer native code.
PiperOrigin-RevId: 196541787
|
|
|
|
|
|
|
|
| |
prevents Bazel from crashing on an ErrorInfo with an exception from
ActionExecutionFunction, which can contain an action, and therefore contain a
NestedSet.
PiperOrigin-RevId: 196533301
|
|
|
|
|
|
| |
BuildOptions$OptionsDiffForReconstruction. The fingerprint uniquely identifies the "baseline" BuildOptions object and the checksum uniquely identifies the "overlay", so we don't need to incorporate the rest of the data.
PiperOrigin-RevId: 196532013
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196527806
|
|
|
|
| |
PiperOrigin-RevId: 196518906
|
|
|
|
|
|
|
| |
separate class
RELNOTES: None.
PiperOrigin-RevId: 196517537
|
|
|
|
|
|
|
| |
Since it's not a provider, it doesn't need the Info suffix anymore.
RELNOTES:none
PiperOrigin-RevId: 196505329
|
|
|
|
|
|
|
| |
Since it's not a provider, it doesn't need the Info suffix anymore.
RELNOTES:none
PiperOrigin-RevId: 196498526
|
|
|
|
|
|
|
| |
The last usages of re2 in Bazel were removed in https://github.com/bazelbuild/bazel/commit/04808943e1c18ed670535d531a4dd435587d584b
RELNOTES: None.
PiperOrigin-RevId: 196498374
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196492364
|
|
|
|
|
|
|
|
| |
For flaky tests, Bazel may have cached information about multiple test attempts. In that case, we might want to post all of them on a subsequent cache hit, rather than posting only the passing attempt.
We currently subclass TestResult inside Google, which overrides the new getCachedTestAttempts method.
PiperOrigin-RevId: 196491575
|
|
|
|
|
|
|
|
|
|
|
| |
This cl enabled skylark rules to create build variables used for C++ compile
actions (in a limited form, e.g. build variables for modules are not exposed
etc).
Working towards #4571.
RELNOTES: None
PiperOrigin-RevId: 196491567
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 196477775
|
|
|
|
|
|
|
|
|
| |
Create junctions to jar's directory when java launcher and its jar are under different drives
Fixed https://github.com/bazelbuild/bazel/issues/5135
Change-Id: I21c5b28f5f36c1fe234f8b781fe40d526db846cc
PiperOrigin-RevId: 196477704
|
|
|
|
|
|
|
|
|
| |
actually added for cc_library's include-attribute. For these, the same path is
present on the command line, but also ignored. For N of those directives, we
currently do O(N^2) prefix checks, which is unnecessarily expensive.
RELNOTES: None.
PiperOrigin-RevId: 196477307
|
|
|
|
| |
PiperOrigin-RevId: 196476639
|
|
|
|
|
|
|
|
|
| |
Change-Id: Id881cc4381fcd355a3b4a65d9089072e4818aa16
Closes #5159.
Change-Id: If14c9a2e55192f5ee5ab384fad27275a24ec12b1
PiperOrigin-RevId: 196472499
|
|
|
|
|
|
| |
and continue to use the embedded JDK as the default host_javabase.
PiperOrigin-RevId: 196471714
|
|
|
|
| |
PiperOrigin-RevId: 196310244
|
|
|
|
| |
PiperOrigin-RevId: 196290095
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196287081
|
|
|
|
|
|
|
| |
Apparently, making one for each target creates memory issues.
RELNOTES: none
PiperOrigin-RevId: 196275764
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 196272337
|
|
|
|
|
| |
RELNOTES: Allow java_toolchain.header_compiler to be an arbitrary executable
PiperOrigin-RevId: 196270007
|
|
|
|
| |
PiperOrigin-RevId: 196266567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/bazelbuild/bazel/issues/5157
If a user's default system locale is not `en`, `en_US` or `en_UK`, there may be a chance that `String#toUpperCase` will result in a string that does not exist in the Enum declaration. This is the case in #5157.
To fix this, it's either
1) setting the Locale in the individual `toUpperCase` calls or
2) set Locale to English by default from `Bazel.java`.
I chose the first because it seemed less intrusive, but I'm open to suggestions.
Closes #5184.
PiperOrigin-RevId: 196261078
|
|
|
|
|
|
|
|
|
|
|
| |
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.
This is encore of https://github.com/bazelbuild/bazel/commit/ecb30676bdd7f1783afb3886e57caa9d6b1b9aee
RELNOTES: None.
PiperOrigin-RevId: 196241212
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 196232710
|
|
|
|
|
|
|
| |
I should have never submitted this as-is. Whoops!
RELNOTES: none
PiperOrigin-RevId: 196160496
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Rolling forward with correct handling for pseudo locale generation flags
*** Original change description ***
Only include generated resources when pseudo locales are asked for.
CompileResources: generate pseudo locales into a separate compiled resource file when the pseudo locale flag is true and the locale is default (e.g. absent). The generated resources must be first in the returned list of compiled resource paths. This allows the user to define custom values to the pseudo locales (which, for some obscure reason, is accepted as a reasonable practice by aapt{,2})
AndroidResourceOutputs: record the type of compiled resource in the comment field of the zip entry for fast comparison.
ResourceLinker: only include the generated resources when the pseudo locale is explicitly asked for. It's important to note that the ordering for compiled resources in the zip goes <generated>...<normal>...<default>. This means the default locale will overwrite the generated locale values. Annoying, but necessary, as that is current order before introducing this cl.
RELNOTES:None
PiperOrigin-RevId: 196159094
|
|
|
|
|
|
|
|
| |
Because of the special nature of aar_import, I don't think it makes much sense
to split up the different parts - you always get everything out of the AAR.
RELNOTES: none
PiperOrigin-RevId: 196152640
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create an AndroidBinaryDataInfo to wrap binary-specific artifacts that
shouldn't be exposed for libraries. This is currently only the final resource
APK.
Continue to extract attribute references from lower-level methods and bubble
them up to the top level.
RELNOTES: none
PiperOrigin-RevId: 196143940
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This provider wraps the other android data providers, as well as artifacts that
should only be made available for top-level Android targets.
This provider is required for some output (such as final data APK) to be
exposed to Skylark, and also makes it easy to pass information from
android_binary data processing to postprocessing actions, most notably resource
shrinking (next reviews).
RELNOTES: none
PiperOrigin-RevId: 196135042
|
|
|
|
| |
PiperOrigin-RevId: 196127040
|
|
|
|
| |
PiperOrigin-RevId: 196113268
|
|
|
|
|
|
|
|
|
| |
CompileResources: generate pseudo locales into a separate compiled resource file when the pseudo locale flag is true and the locale is default (e.g. absent). The generated resources must be first in the returned list of compiled resource paths. This allows the user to define custom values to the pseudo locales (which, for some obscure reason, is accepted as a reasonable practice by aapt{,2})
AndroidResourceOutputs: record the type of compiled resource in the comment field of the zip entry for fast comparison.
ResourceLinker: only include the generated resources when the pseudo locale is explicitly asked for. It's important to note that the ordering for compiled resources in the zip goes <generated>...<normal>...<default>. This means the default locale will overwrite the generated locale values. Annoying, but necessary, as that is current order before introducing this cl.
RELNOTES:None
PiperOrigin-RevId: 196111843
|
|
|
|
|
|
|
|
| |
Users shouldn't worry too much about it, we will soon recommend
using Buildifier.
RELNOTES: None.
PiperOrigin-RevId: 196025297
|
|
|
|
|
| |
RELNOTES: none
PiperOrigin-RevId: 196024071
|
|
|
|
|
|
|
|
| |
Explicitly work with rele attributes at (or closer to) the top level rather
than deep in the code.
RELNOTES: none
PiperOrigin-RevId: 196004542
|