| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
of DefaultInfo() was used.
RELNOTES: None.
PiperOrigin-RevId: 202192091
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This skydoc rewrite uses an actual skylark interpreter with a faked build API (implementing the actual build API that Bazel uses).
There's a lot left to do here, this is a barebones start.
For example, this does not yet handle:
- load() statements
- non-global build API elements (e.g. apple_common)
- output of any rule information other than attribute names
- markdown output format
RELNOTES: None.
PiperOrigin-RevId: 202187207
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 202167782
|
|
|
|
|
|
|
|
| |
Logger messages aren't printed to the console, they're written to /usr/local/google/tmp, and can be prohibitively large for these debug server logs.
Instead I'm going with your original suggestion in https://github.com/bazelbuild/bazel/commit/b74922932b25a71c626b47ea9a9afb7dbc506cec, and selectively suppressing debug events by wrapping the EventHandler on the way in to SkylarkDebugServer.
PiperOrigin-RevId: 202166571
|
|
|
|
|
|
|
|
|
| |
Consolidate the creation of JavaCompilationArgsProviders, and avoid explicit
handling of the 'direct' and 'recursive' cases in clients. Also add some
higher-level methods to the builder API to support adding dependencies
with dep/export/runtime_dep-like semantics.
PiperOrigin-RevId: 202166383
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 202162804
|
|
|
|
| |
PiperOrigin-RevId: 202162534
|
|
|
|
|
|
|
|
|
| |
CppCompileAction.discoverInputsStage2 retrieves values of discovered modules
from ActionExecutionValue.
This addresses a possible a correctness issue.
PiperOrigin-RevId: 202162180
|
|
|
|
| |
PiperOrigin-RevId: 202151257
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 202150316
|
|
|
|
|
|
|
| |
This was never used. We thought it will be useful, but it's not.
RELNOTES: None.
PiperOrigin-RevId: 202143524
|
|
|
|
|
|
|
| |
Makes it non-instantiable so that it's easier to migrate SWIG rules to Skylark.
RELNOTES:none
PiperOrigin-RevId: 202136054
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also handle statements in conditional breakpoints.
This is more consistent with other common debuggers (e.g. java, python).
Calls Parser#parseStatement with local parsing level, so some statement types aren't handled (e.g. load statements), which is broadly consistent with other debuggers.
Assignment, augmented assignment, and return statements return a non-None value,
and simple expression statements still return the result of evaluating the expression.
TAG_CHANGE_OK=This proto has never yet been used
TYPE_CHANGE_OK=This proto has never yet been used
PiperOrigin-RevId: 202135678
|
|
|
|
|
|
|
|
|
|
|
|
| |
add helper JUnit TestWrapper class to do some action on test timeout
i.e. we want to dump the current state of the test on timeout before
exit
for the new junit integration test framework
Closes #5436.
PiperOrigin-RevId: 202123320
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 202118168
|
|
|
|
|
|
|
| |
they are used on the phone.
RELNOTES: None.
PiperOrigin-RevId: 202117007
|
|
|
|
|
|
| |
and for often required operations like creating file and its parent directories
PiperOrigin-RevId: 202115025
|
|
|
|
|
|
|
| |
As //tools/defaults will be deprecated soon. All usages of //tools/defaults:jdk and //tools/defaults:java_toolchain should be replaced by corresponding targets in //tools/jdk/BUILD package
RELNOTES:none
PiperOrigin-RevId: 202114489
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, Bazel expected that it can compile whatever appeared in cc_library.srcs
directory artifacts. That is true for C/C++ source files, and for headers when
the C++ toolchain supported header parsing/processing (which used
CppCompileAction). When the toolchain doesn't support header parsing/processing,
Bazel would crash.
Addresses issue #5092. One part of it.
Fixes #5372.
RELNOTES: None.
PiperOrigin-RevId: 202114286
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the tests had been disabled for flakyness due to
timeouts. I think the right solution is remove the
individual test timeouts as on a highly loaded
machine fine grained timeouts typically don't make
much sense.
After removing the individual test timeouts no more
flakyness was found in 1000 runs.
Closes #5465.
PiperOrigin-RevId: 202113697
|
|
|
|
|
|
| |
Closes #5435.
PiperOrigin-RevId: 202100672
|
|
|
|
|
|
|
|
|
| |
To get a CcCompilationInfo instance from Skylark it will either have to be
through its constructor (not yet fully implemented) which will not schedule any
actions or through a call to compile() which does schedule actions.
RELNOTES:none
PiperOrigin-RevId: 202099841
|
|
|
|
| |
PiperOrigin-RevId: 202092962
|
|
|
|
| |
PiperOrigin-RevId: 202023187
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 202015490
|
|
|
|
|
|
|
| |
interfaces.
RELNOTES: None.
PiperOrigin-RevId: 201972439
|
|
|
|
| |
PiperOrigin-RevId: 201969238
|
|
|
|
|
|
|
|
| |
I should have left it as it was -- doing it client-side is just too
slow.
ENUM_VALUE_OK=This proto has never yet been used
PiperOrigin-RevId: 201957138
|
|
|
|
|
|
|
| |
interfaces.
RELNOTES: None.
PiperOrigin-RevId: 201956915
|
|
|
|
|
|
|
|
|
|
| |
I will remove the CcLinkParamsStore class in a separate CL. For now, make sure
the API doesn't expose this class.
The only Skylark use was in cc_import which is migrated in this CL.
RELNOTES:none
PiperOrigin-RevId: 201948058
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The native launcher can now launch Java and Bash binary in
directory with non-English characters.
Unfortunately, python doesn't support running python zip file under
directory with non-English characters. eg. python ./??/bin.zip will
still fail.
See https://github.com/bazelbuild/bazel/issues/4473
Change-Id: I77fe9cdaabffc2e0d25c7097da5c0c9333a9c4a3
PiperOrigin-RevId: 201939391
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When extracting embedded binaries, the client now
caches which directories it has already created
and won't attempt creating them again.
This saves some time on Windows: from 16.3 sec on
average down to 13.2 sec. (n=10 runs, always
starting Bazel with a new --output_user_root and
shutting down afterwards.)
On Linux I see only a marginal speedup, not
significant enough to claim credit for it. :)
See https://github.com/bazelbuild/bazel/issues/5444
Closes #5448.
PiperOrigin-RevId: 201933181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Bazel client on Windows is now 50% faster to
check the embedded tools than it was before.
Results:
- Linux: 20 ms -> 6 ms
- Windows: 294 ms -> 133 ms
Measurements were done with n=10 runs and a hot
server, using blaze::GetMillisecondsMonotonic().
Previously the client performed the same tasks
multiple times while trying to determine if a path
was a good extracted binary. (E.g. converted the
path to Windows format multiple times, checked if
it was a directory twice, opened the path twice.)
Now the client performes these tasks only once,
e.g. it converts path once and stats only once.
See https://github.com/bazelbuild/bazel/issues/5444
Closes #5445.
PiperOrigin-RevId: 201913758
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 201748802
|
|
|
|
|
| |
Change-Id: I355b138e143771fd826ab03951df821ea7d58ac5
PiperOrigin-RevId: 201740564
|
|
|
|
|
|
|
| |
interfaces.
RELNOTES: None.
PiperOrigin-RevId: 201735466
|
|
|
|
| |
PiperOrigin-RevId: 201723154
|
|
|
|
|
|
|
| |
label methods that don't explicitly pass a repository mapping.
RELNOTES: None
PiperOrigin-RevId: 201717665
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
see b/109887056
*** Original change description ***
Stop objc_proto_library from returning the generated sources.
PiperOrigin-RevId: 201709908
|
|
|
|
|
|
| |
ArtifactResolverSupplier in SkyframeExecutor.
PiperOrigin-RevId: 201705857
|
|
|
|
|
|
|
|
|
|
|
| |
Like with providers, consumers get a merged view of all actions from the merged configured target (all other aspects + the base target).
I had to rejig the aspect value / configured aspect to be symmetric with rule configured targets.
I do not expect significant memory bloat from this. All lists / maps already existed, only extra fields have been added.
RELNOTES: Expose aspect actions provider to Skylark.
PiperOrigin-RevId: 201697923
|
|
|
|
|
|
|
|
| |
RELNOTES: None
*** Reason for rollback ***
PiperOrigin-RevId: 201686843
|
|
|
|
|
|
| |
FileStatus.
PiperOrigin-RevId: 201683773
|
|
|
|
| |
PiperOrigin-RevId: 201680493
|
|
|
|
|
|
|
|
| |
This will be necessary for the action graph query which operates on
ConfiguredTargetValue's.
RELNOTES: None
PiperOrigin-RevId: 201657526
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 201653054
|
|
|
|
|
|
|
| |
This is in preparation for interleaving them.
RELNOTES: None
PiperOrigin-RevId: 201652267
|
|
|
|
|
|
|
|
| |
of the --worker_verbose setting.
This message is important because it can catch cases where people are unknowingly running consecutive builds with different options, leading to much slower builds. In this regard it is a lot like "Build options have changed, discarding analysis cache".
PiperOrigin-RevId: 201648554
|
|
|
|
|
|
|
|
|
| |
enum.
Now that we aren't using enum names for the hash functions, we also accept the standard names, such as SHA-256.
RELNOTES: None.
PiperOrigin-RevId: 201624286
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 201617188
|