| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we receive an event indicating that the build is over, we first
post that event and then clear up all pending event by stating that
their prerequisite event was aborted (which we can safely assert, as
we know we will not process any further events).
Now, if a build is aborted (e.g., user interruption) before the build
starting event is generated, the streamer can receive a build-finished
event while still having an event (e.g., the raw command line) blocked
on the build-starting event. So the canonical order of clearing the stream
would send a build-finished event before the build-starting event, which
can be confusing to consumers of the stream. Therefore, if have to generate
an artificial aborted build-starting event, do so first (including clearing
the events blocked on the build-starting event) and only afterwards post
the build-finished event in the stream.
Change-Id: Ib33f16f74b7bee7a963df94bbcad7a56db9f07e3
PiperOrigin-RevId: 172305114
|
|
|
|
|
|
|
|
|
|
| |
There is a conceptual difference between the (maybe unsuccessful) completion
of a top-level target and a label as the root cause for a failure (i.e., a
missing source file). Indicate that difference as such, by having a separate
message for failures associated with an unconfigured label.
Change-Id: I3f2e20d4dc85782eb11b104a7baf089e66d972e7
PiperOrigin-RevId: 172299938
|
|
|
|
|
|
|
|
|
| |
opposed to only through ctx.fragments.apple)
Progress towards #3424.
RELNOTES: None.
PiperOrigin-RevId: 172299240
|
|
|
|
|
|
|
| |
Make them specify the target pattern evaluator they need.
RELNOTES: None
PiperOrigin-RevId: 172296001
|
|
|
|
|
|
| |
TESTED=added remote test
RELNOTES: Fixes #2574
PiperOrigin-RevId: 172294781
|
|
|
|
| |
PiperOrigin-RevId: 172199420
|
|
|
|
|
|
|
| |
This will make it easier to pass only error-handling functionality into support classes.
RELNOTES: None.
PiperOrigin-RevId: 172148072
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 172133468
|
|
|
|
|
|
|
|
|
|
|
| |
This simple system allows blaze developers to insert instrumentations in particular methods that they want to know:
1. How often are they called?
2. From which call sites are they called, with full call stack
The output is a pprof file that can then be analysed offline.
PiperOrigin-RevId: 172128440
|
|
|
|
|
|
|
| |
Remove an unnecessary warning and make all warnings for option conflicts print only if the option values are not equal.
RELNOTES: None.
PiperOrigin-RevId: 172124261
|
|
|
|
|
|
|
|
|
| |
We added a proto to third_party, and protos aren't compiled as per normal during bootstrapping. We add a pointer from our protobuf into third_party for pprof so
bootstrapping can work.
Verified that this fixes test by exporting a repo and running bazel test.
PiperOrigin-RevId: 172122010
|
|
|
|
| |
PiperOrigin-RevId: 172115471
|
|
|
|
|
|
|
|
|
| |
RELNOTES[INC]: += on lists now mutates them. `list1 += list2` is now equivalent
to `list1.extend(list2)` and not equivalent to `list1 = list1 + list2` anymore.
Fixes #2350.
PiperOrigin-RevId: 172111899
|
|
|
|
|
|
|
| |
builder code.
RELNOTES: None
PiperOrigin-RevId: 172109520
|
|
|
|
|
|
| |
direct files into the deps attribute, only proto_library and objc_proto_library targets are allowed.
PiperOrigin-RevId: 172107133
|
|
|
|
|
|
| |
which causes the package containing the reference to be visited in rbuildfiles (which isn't the intended behaviour of rbuildfiles). Also add tests to guard against other types of inclusions.
PiperOrigin-RevId: 172106051
|
|
|
|
|
|
|
|
|
|
| |
Change ceb1013c1ca0238188e2714442fcfb2efb16bc6a added an event for
the structured command line to the BEP. Announce that event as a
child of the build-starting event so that it gets properly chained
and does not have to be chained in by a progress event.
Change-Id: I6aeb46b748a536da58a916b9c4e0b1b66bbd40b0
PiperOrigin-RevId: 172100341
|
|
|
|
|
|
|
| |
Make them specify the target pattern evaluator they need.
RELNOTES: None
PiperOrigin-RevId: 172100319
|
|
|
|
|
|
| |
http://https://github.com/bazelbuild/bazel/commit/5b4b7a3ebb83a8c93d8f68ade7bf1242c8590256
PiperOrigin-RevId: 172099288
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 172087232
|
|
|
|
|
|
|
| |
ConfigurationFragmentFactory instances to contents of BUILD files and to the file system.
RELNOTES: None.
PiperOrigin-RevId: 172086610
|
|
|
|
|
|
|
| |
Whether or not there was a catastrophic error is stored in the SpawnResult, so
we can just use that instead of passing in an additional boolean.
PiperOrigin-RevId: 172083752
|
|
|
|
|
|
|
| |
instead of the one computed based on xcode_config.
RELNOTES: None.
PiperOrigin-RevId: 172064337
|
|
|
|
| |
PiperOrigin-RevId: 172053593
|
|
|
|
| |
PiperOrigin-RevId: 172007131
|
|
|
|
| |
PiperOrigin-RevId: 171980809
|
|
|
|
|
|
|
| |
Having a short canonical name for each kind of finding (the category) makes it easier to document all the lints and for users to find the documentation for each lint.
RELNOTES: none
PiperOrigin-RevId: 171972645
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In https://github.com/bazelbuild/bazel/commit/f426544e67170d31b9d228ecf4cdc4b6ce1ba00d I updated osx_cc_wrapper to work correctly in case both
precompiled .so and cc_library-made .so are linked into a single binary. This cl
makes osx_cc_wrapper work also when a precompiled .dylib is provided.
This is roll-forward of https://github.com/bazelbuild/bazel/commit/0257c29f496719bb8414d012334155de6bbefa11.
Fixes #3450 again for dylibs
Fixes #407
One step closer to finishing #1576
RELNOTES: None.
PiperOrigin-RevId: 171969333
|
|
|
|
|
|
|
|
|
|
| |
The `set` constructor used to be deprecated, but it was still possible to use
it by providing --incompatible_disallow_set_constructor=false.
RELNOTES[INC]: The flag --incompatible_disallow_set_constructor is no longer
available, the deprecated `set` constructor is not available anymore.
PiperOrigin-RevId: 171962361
|
|
|
|
| |
PiperOrigin-RevId: 171960869
|
|
|
|
|
|
|
|
|
|
|
| |
Removes the special casing of implicit requirements. Accumulating them and parsing them at the end of the parse() function was never enough to actually guarantee that the value not be replaced. I've gone through all options with implicit requirements to make sure that the expectation is checked after options parsing, so this change should be relatively safe.
Implicit requirements is still a broken concept - they don't actually expand based on the value given, so a user that is explicitly NOT setting a flag might unwittingly be setting all the requirements for that unset flag. Removing it fully requires redesigning or removing the flags that set it, though, so for now we are standardizing the behavior so that it behaves like any other expansion options, just one with a value.
Also consolidate the deprecated wrapper option behavior into the expansion work. It will soon be removed entirely, but for now it can get grouped in with the expansion logic, so that its differences are more explicit.
RELNOTES: None.
PiperOrigin-RevId: 171957502
|
|
|
|
|
|
|
| |
The transition period is over, these features have now been rolled out.
RELNOTES: --experimental_use_parallel_android_resource_processing and --experimental_android_use_nocompress_extensions_on_apk are removed. These features are fully rolled out.
PiperOrigin-RevId: 171957383
|
|
|
|
|
|
|
| |
Fixes #3874.
Change-Id: Ibbe3ea27b77426f551e2f70f082478edb2234749
PiperOrigin-RevId: 171957230
|
|
|
|
|
|
|
|
| |
RELNOTES[INC]: The flag --incompatible_descriptive_string_representations is no
longer available, old style string representations of objects are not supported
anymore.
PiperOrigin-RevId: 171952621
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed a problem where if you have a workspace with basename
"server", clean will rudely delete the server's pid file and cause it
to commit suicide. This is because clean deletes the deep and non-deep
execroot, presumably temporarily as part of the deep execroot
migration. --deep_execroot has been enabled for more than a year now,
so hopefully we can safely remove this aggressive deleting. --expunge
can take care of old execroots if needed.
Change-Id: I445b0d7cedf2fb9a6a365eacc85b75428a981640
PiperOrigin-RevId: 171948100
|
|
|
|
|
|
|
| |
Previously, the location of the warning was the whole file. Now it is 1:1-2:1. This doesn't make sense if the file is empty but I think it's good enough since that's an edge case.
RELNOTES: none
PiperOrigin-RevId: 171942703
|
|
|
|
| |
PiperOrigin-RevId: 171933076
|
|
|
|
|
|
| |
handle it properly.
PiperOrigin-RevId: 171906091
|
|
|
|
| |
PiperOrigin-RevId: 171906076
|
|
|
|
| |
PiperOrigin-RevId: 171905267
|
|
|
|
|
|
| |
informative if the number of summaries and the number of test targets don't agree. My guess is somehow we have duplicate configured targets?
PiperOrigin-RevId: 171904831
|
|
|
|
|
|
|
|
| |
method desugaring for Android.
RELNOTES: none
PiperOrigin-RevId: 171891682
|
|
|
|
|
|
| |
the tool setup we do in tests doesn't necessarily have to be copied if we copy a workspace over.
PiperOrigin-RevId: 171864170
|
|
|
|
|
|
|
|
| |
Minor change, but the Rules AppEngine now supports Python with Google App Engine, so it's more than just Java.
Closes #3837.
PiperOrigin-RevId: 171843168
|
|
|
|
|
|
|
| |
This only covers functions deprecated in the same file. It does not yet recognize load()ed functions that are deprecated in another file.
RELNOTES: none
PiperOrigin-RevId: 171841455
|
|
|
|
|
|
|
| |
The semantics of implicit requirements will soon change to adding the requirements in-place in the command line. This particular implicit requirement was not necessary.
RELNOTES: None.
PiperOrigin-RevId: 171841036
|
|
|
|
|
|
|
| |
...to avoid occasional time outs in the remote-execution environment.
Change-Id: I9bacabdd27780d8eabf80a6b257830d2f831ea58
PiperOrigin-RevId: 171839158
|
|
|
|
|
|
| |
CcToolchainProvider#getToolPathFragment.
PiperOrigin-RevId: 171837541
|
|
|
|
|
|
|
| |
The semantics of implicit requirements will soon change to adding the requirements in-place in the command line, so they will be slightly more likely to get overwritten. Explicitely check that the requirement is set, and warn appropriately if the user is sending mixed signals.
RELNOTES: None.
PiperOrigin-RevId: 171824297
|
|
|
|
|
|
| |
CppConfiguration#getLdExecutable to CcToolchainProvider.
PiperOrigin-RevId: 171818406
|