| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
| |
For now we will only block Java recursive globs. Any other languages or
extensions can be banned relatively easily.
RELNOTES:
Add lint check for discouraging glob(["**/*.java"])
PiperOrigin-RevId: 185417760
|
|
|
|
|
|
|
|
| |
to ConfiguredTarget.GetTarget(). Also remove equivalence requirements for
the ConfiguredTarget's target and the stored Target since there will soon no
longer be a Target in ConfiguredTarget.
PiperOrigin-RevId: 185417468
|
|
|
|
|
|
|
|
| |
This enables writing tests for android_instrumentation_test that mock
android_binary using a skylark rule that returns an AndroidInstrumentationInfo.
RELNOTES: None
PiperOrigin-RevId: 185417182
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 185412809
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ExperimentalEventHandler is in charge of composing the pretty progress bar
that Bazel displays. This progress bar is a multi-line message with control
characters printed on the terminal.
The progress bar was composed by issuing many individual writes to an
AnsiTerminal. Because the AnsiTerminal in this case was backed by an error
stream (which are unbuffered), each of these writes resulted in a gRPC to
the Bazel client to write the message to the console. gRPC calls are much
more expensive than calls to a file descriptor, and, in general, even small
writes to a file descriptor should be avoided when preparing long messages.
To fix this, fully buffer the output messages sent to the AnsiTerminal until
explicitly flushed. ExperimentalEventHandler was already doing the right
thing regarding flushes but did not account for the fact that each write
would be (unintentionally) sent directly to the terminal.
The flicker was significant: on a pathological case (building sandboxfs with
Bazel on my MacBook Pro 13" on macOS), this change shaves about 5 seconds of
build time on the previous 45 second-long build. I think this only happened
with "bazel run" and "bazel test" invocations and not "bazel build", but
I haven't really confirmed this.
RELNOTES: None.
PiperOrigin-RevId: 185405892
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 185398389
|
|
|
|
|
|
|
|
| |
We already intern the labels themselves. Benchmarks do not show any further
gain by interning the label names.
RELNOTES: None
PiperOrigin-RevId: 185394812
|
|
|
|
|
| |
Change-Id: Id898aafaf1a5dec16e5639f50981c1051caa70eb
PiperOrigin-RevId: 185390071
|
| |
|
|
|
|
| |
PiperOrigin-RevId: 185381597
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 185378771
|
|
|
|
|
|
| |
Closes #4623.
PiperOrigin-RevId: 185378490
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 185377450
|
|
|
|
|
|
|
|
|
|
|
|
| |
"tail --pid" is supported.
The solutions aren't mine, the new test was taken from Ola's unknown commit and the way to avoid race condition courtesy of sethkoehler@
Mitigates #4608 for compatible Linux systems.
TESTED=manual scripts and new test case.
RELNOTES: None
PiperOrigin-RevId: 185374273
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 185372459
|
|
|
|
|
|
|
|
| |
objc_library that it depends on.
See https://github.com/bazelbuild/bazel/issues/3352
PiperOrigin-RevId: 185371993
|
|
|
|
| |
PiperOrigin-RevId: 185370712
|
|
|
|
| |
PiperOrigin-RevId: 185369902
|
|
|
|
|
|
|
| |
The file can be generated during execution by a different rule.
RELNOTES:none
PiperOrigin-RevId: 185361140
|
|
|
|
|
|
| |
Closes #4610.
PiperOrigin-RevId: 185359400
|
|
|
|
|
|
|
|
| |
I don't think it's worth repeating things here. Let's point to the main
documentation.
RELNOTES: None.
PiperOrigin-RevId: 185356504
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In MSVC, `environ` is a macro (from `stdlib.h`):
```cpp
extern char*** __p__environ(void);
#define _environ (*__p__environ())
#define environ _environ
```
So `extern char **environ;` will be expanded as `extern char **(*__p_environ());` which is invalid. This causes compile warning on MSVC.
Closes #4487.
PiperOrigin-RevId: 185354631
|
|
|
|
| |
PiperOrigin-RevId: 185354353
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 185353994
|
|
|
|
|
|
|
|
|
|
|
| |
...even where they should be clear from the evaluation order.
Since reporting sometimes happens in different threads, there
might be races on the event bus. Explicit order constraints
allow the BuildEventStreamer to reorder those events correctly
in the case of a lost race.
Change-Id: Ib5211341c2016527e9268e8fdbd1677d4255b23c
PiperOrigin-RevId: 185345738
|
|
|
|
|
|
|
|
|
|
| |
Context implementations are currently empty, just doing the plumbing in this
change. Once this is in we can start passing along the ObjectCodecRegistry, which
will allow runtime codec resolution for classes not known at compile time.
We'll also inevitably add some memoization helpers, allowing us to optimize the
serialization process further.
PiperOrigin-RevId: 185305674
|
|
|
|
|
|
|
|
|
| |
android_local_test generates and R.class file and so this is necessary for projects that don't nest their BUILD files under a java/ or javatests/ root.
Fixes #4618
RELNOTES: None
PiperOrigin-RevId: 185281836
|
|
|
|
|
|
|
|
| |
- make Objects.requireNonNull and Long.compare rewrites compatible with --core_library
- apply those and try-with-resources rewrites to generated companion classes
RELNOTES: None.
PiperOrigin-RevId: 185262256
|
|
|
|
| |
PiperOrigin-RevId: 185255326
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 185218745
|
|
|
|
| |
PiperOrigin-RevId: 185215813
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 185215175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Breaking targets in 2018.02.08 and 2018.02.09 nightly TGPs
There were some merge conflicts in this rollback CL. See unknown commit for the unresolved version. I kept the YOURS sections, and ran fiximports.py to remove unused imports.
See b/73157879
*** Original change description ***
C++: Remove last instatiation of CppModel outside CcLibraryHelper.
This is the second try for this CL. The first one caused Blaze to crash when building Exoblaze as shown in b/72936965. In this CL I fix the condition of when to generate non-PIC compilation actions for WrapCcHelper.
RELNOTES:none
PiperOrigin-RevId: 185203398
|
|
|
|
|
|
| |
codec, but whose parent classes have codecs. This is ok because the polymorphic strategy doesn't need an instance of the grandchild class: the parent class is fine, so long as it has a codec.
PiperOrigin-RevId: 185200943
|
|
|
|
| |
Change-Id: Id636879aeab94916fcaed3c067e4077215ebc6df
|
|
|
|
|
| |
Change-Id: I1fa7867ffb08af95c1eef5ae3e32cff34292328b
PiperOrigin-RevId: 185189976
|
|
|
|
|
|
|
| |
This can be computed on the fly if we need it.
RELNOTES: None
PiperOrigin-RevId: 185180257
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a rollforward with fixes.
The values (if present) are written into the manifest with this format:
Target-Label: <label>
Injecting-Rule-Kind: <kind>
In the future, JavaBuilder will make sure of this instead of command line arguments to find owners for jars for its add_dep commands.
PiperOrigin-RevId: 185159950
|
|
|
|
|
|
|
| |
This matches the current behavior on Linux. When an extended attribute is not present on a file, getxattr on Linux returns ENODATA whereas getxattr on Mac returns ENOATTR. Previously, we were special casing ENODATA to not throw an exception but not ENOATTR. Now we treat them the same.
RELNOTES: None
PiperOrigin-RevId: 185157964
|
|
|
|
|
|
| |
BuildConfiguration.
PiperOrigin-RevId: 185155423
|
|
|
|
|
|
|
| |
Built at:
https://github.com/google/turbine/commit/2c7d1193e10c424cd236365d373aa4227a1f5ab5
Change-Id: I4cbb9e52b56f26ba88b019b63ee8e19a5f7fad2a
|
|
|
|
| |
PiperOrigin-RevId: 185153485
|
|
|
|
|
|
| |
TargetCompletedEvent.
PiperOrigin-RevId: 185150827
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Cascade rollback to unbreak bazel tests
*** Original change description ***
Update ijar tests to verify time stamp.
***
PiperOrigin-RevId: 185147605
|
|
|
|
|
|
|
| |
This argument is unused and should be removed.
RELNOTES: None
PiperOrigin-RevId: 185147327
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 185145663
|
|
|
|
| |
PiperOrigin-RevId: 185143078
|
|
|
|
| |
PiperOrigin-RevId: 185140903
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 185138928
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a test to //src/test/py/bazel:runfiles_test
that ensures that Java binaries using the Java
runfiles library in @bazel_tools can find their
runfiles, even if JAVA_RUNFILES and the RUNFILES_*
envvars are undefined.
There's already a shell script test for this in
//src/test/shell/bazel:java_launcher_test, but we
don't run that on Windows, shell tests are slower
on Windows than on Linux anyway, and adding this
test was very little work. Plus I'll need the new
Bar.java file for other tests that are coming.
See https://github.com/bazelbuild/bazel/issues/4460
Change-Id: Ie0fa51046c3f3a1e5ece7a6206131261a5a5b1f8
PiperOrigin-RevId: 185137988
|