| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
The intend is to move the profiler setup earlier in the startup sequence, so we
can get more profiler coverage. Ideally, we'd setup the profiler immediately
after getting the client call, but this is not currently possible due to the
requirement that initialization and shutdown happen in pairs (otherwise the
next command invocation crashes with an exception from the Profiler).
PiperOrigin-RevId: 200707029
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using that repository rules now may return a non-None value,
make git_repository return the arguments that make the rule
reproducible; in particular, return the actual commit (instead
of a tag) and the date of the commit, so support shallow clones.
The added test also demonstrates how the `bazel sync` command
together with `--experimental_repository_resolved_file` can be
used to replay an earlier state of external dependencies.
Change-Id: Ifa1cfdfdb5eb299a15b9d0ec7d285dc84c0bcdc0
PiperOrigin-RevId: 200705705
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They weren't actually doing anything. With default flags, createHandler never
returns a FancyTerminalEventHandler, because that always gets wrapped in a
RateLimitingEventHandler. Even so, under normal circumstances, the fancy
terminal event handler always leaves the terminal in a valid state at the end
of each printed line. We can only end up in a bad state if the blaze server is
killed, but even then, this code wasn't doing anything because it didn't get to
run.
The only way to guarantee that the terminal is always in a valid state is to
make sure that every stdout/stderr buffer we send to the client ends with a
reset code sequence. The experimental ui handler is better at sending only
complete buffers (we were previously using an auto-line flushing output stream,
which didn't allow the event handler to reason about how much stuff got
actually printed in a single write call).
Anyway, I think we're in a better place now, and this code wasn't run, and if
we want to fix it properly (if the switch to experimental_ui isn't sufficient),
then we need to fix it elsewhere.
PiperOrigin-RevId: 200699609
|
|
|
|
|
|
| |
This is in preparation for interleaving config creation with loading+analysis.
PiperOrigin-RevId: 200695071
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Background: the original code is implementing the OutputStream interface. Given a sequence of write calls, the code puts each of these writes into a queue. On the other side of the queue is an unbounded thread pool, which takes the writes off the queue one by one, and then does individual blocking writes with a fixed file offset.
There are three problems with the original code:
1. Writes are sent to the Kernel one-by-one. Imagine if the incoming writes a single-byte writes, then we do one kernel call for every single byte. This is the worst case.
2. Due to multithreading, the writes can get reordered. In the worst case, the order is reversed, and the kernel flushes each write to disk individually. Since the writes are not aligned to disk block boundaries, each write has to first *read* the block from disk, overwrite a few bytes, and then flush the block back to disk. On a spinning platter, this is the worst possible sequence of operations: write a block, read the same block back, write the same block again, read the same block back, etc., with each operation having to wait for a full disk rotation.
Note that this gets worse if there's high thread and / or disk contention, e.g., when running a build system in the background.
3. Due to the unbounded thread pool, it may end up creating a new thread for every single write (possibly as many as one per byte written). This is also the worst case, although it's probably negligible compared to 1+2.
Compared to that, this change uses an in-memory buffer before sending writes to the kernel so non-block sized writes are batched, it writes sequentially, and it uses a single thread created at the start. A single thread should be more than able to fully saturate local disk I/O, so multi-threading should ~never be a improvement here.
This might look different if we had perfectly aligned writes of an integer multiple of the disk block size to a distributed network file system or a local SSD raid. If you look at the clients of this class, that's definitely not the case: this code is primarily used for local file BEP transports - we wouldn't use local file BEP transports to write to a network file system, we'd use the BES instead. It's also used to write a couple of log files, also all local - otherwise we'd add the data to BEP. These are all unaligned, ~random-sized writes.
If we created a lot of these files, then using a thread pool with fewer threads than files and using non-blocking I/O might be an improvement due to the reduction in thread count, but I think it's very unlikely that we'll ever need that complexity.
PiperOrigin-RevId: 200694423
|
|
|
|
|
|
|
| |
- reduce the parameters to the minimum required
- change to void, move additional setup into the method
PiperOrigin-RevId: 200692559
|
|
|
|
|
|
|
| |
in Bazel osx CROSSTOOL. -lgcov is not supported on macOS. See #5128.
RELNOTES: None.
PiperOrigin-RevId: 200691758
|
|
|
|
|
|
|
|
|
| |
Change-Id: I1039371e326dc260f2e70b32c9f4e2fd0dc0d7a6
Closes #5395.
Change-Id: I002ba4f0944594ab62a7dd7a3ed4b4e7438328c0
PiperOrigin-RevId: 200686443
|
|
|
|
|
|
|
|
| |
This should be a no-op, mostly replacing PathConverter with
BuildEventArtifactUploader, since none of the implementations perform any
upload yet.
PiperOrigin-RevId: 200685325
|
|
|
|
|
|
| |
ConfiguredTargetValue is no longer prohibitively slow.
PiperOrigin-RevId: 200640971
|
|
|
|
|
|
|
|
| |
make Artifact#equals take owner into account (unknown commit). In the case that shared actions generate tree artifacts, the outputs of the second action do not include all the artifacts present in the results of the first action, because those artifacts were not known until execution. However, corresponding artifacts can be created easily enough, with the proper owners.
Fixes #5396
PiperOrigin-RevId: 200640969
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After this change, Bazel prints a warning when
--use_top_level_targets_for_symlinks is active and the destination of
a symlink would be ambiguous.
This also includes a refactoring of OutputDirectoryLinksUtils to use a
single source of truth for all symlink operations. This results in a
few small visible behavior changes:
* Bazel used to delete a convenience symlink with the name of the
workspace from the WORKSPACE file... but it didn't create it.
* Bazel used to check for a convenience symlink named "includes" when
pretty-printing paths... but it didn't create it.
* Bazel used to ignore the existence of the "testlogs" symlink when
pretty-printing paths... despite that it created it.
* Bazel used to prioritize the execroot over the output base when
pretty-printing paths... despite that the former contains the latter.
RELNOTES: None.
PiperOrigin-RevId: 200629863
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that this is not sufficient to see caching between builds on its own;
currently when any flag changes, the analysis cache is reset. A follow-up
will turn off this behavior when only test flags change while
trim_test_configuration is on.
config_settings which examine test options are treated the same as test rules;
that is, they can only be successfully analyzed at the top level or when
connected to the top level by an unbroken chain of test rules.
RELNOTES: None.
PiperOrigin-RevId: 200614584
|
|
|
|
|
|
| |
*** Reason for rollback ***
PiperOrigin-RevId: 200605975
|
|
|
|
| |
PiperOrigin-RevId: 200593618
|
|
|
|
|
|
|
| |
Deprecates the flag, though it continues to exist as a no-op so that users get a warning before errors.
RELNOTES: --noexpand_configs_in_place is deprecated.
PiperOrigin-RevId: 200572053
|
|
|
|
| |
PiperOrigin-RevId: 200561008
|
|
|
|
|
|
| |
callables that depend on CToolchain in CppConfiguration.
PiperOrigin-RevId: 200559893
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When pretty printing a Skylark value, lists are presented as the
opening bracket on a line by itself, each entry on its own line,
and the closing bracket again on its own line. While this generally
improves readability, for the empty list this is not the case, as
the expression [] can easily be understood at a glance. In fact, the
additional line even makes the outer structure harder to see, as it
is spread over even more lines. Therefore, shorten the printing of
the empty list to be on a single line.
Change-Id: I032d1550b1f99bce47dbec7e77a4d5c6656d78a1
PiperOrigin-RevId: 200558784
|
|
|
|
|
|
|
|
| |
with empty default value to keep the script behavior unchanged. javac is not given a large enough max heap on Raspberry Pi 3. This change but allows the user to override the setting.
RELNOTES:
The BAZEL_JAVAC_OPTS environment variable allows arguments, e.g., "-J-Xmx2g", may be passed to the javac compiler during bootstrap build. This is helpful if your system chooses too small of a max heap size for the Java compiler during the bootstrap build.
PiperOrigin-RevId: 200557606
|
|
|
|
| |
PiperOrigin-RevId: 200555806
|
|
|
|
|
|
|
|
|
|
|
| |
See https://github.com/bazelbuild/bazel/issues/4930
Change-Id: I148c0b1e4baa8ff44d86a6ee196bea7e9058320f
Closes #5387.
Change-Id: Iba32f21ff6cad1b538c72cfd08ce24846843c124
PiperOrigin-RevId: 200554084
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
frames in thread paused events.
I started implementing conditional breakpoints server-side in
unknown commit, but:
- client-side implementations seem more common in debugging protocols
- IntelliJ in particular has great support for client-side conditional
breakpoints, but poor support for server-side
- it's unnecessary extra complexity for the server -- simple line
breakpoints + evaluation requests already give us conditional bps.
Also removing frames from thread paused events. It results in poor
performance for stepping and pausing (in which we get frame info for
potentially dozens of threads), and again isn't usual for debuggers.
Finally, ignore breakpoints when performing a client-requested
evaluation.
PiperOrigin-RevId: 200547972
|
|
|
|
|
|
|
|
|
|
|
| |
Make all external repositories depend on an additional SkyValue controllable
via commands, so support unconditional fetching of all external repositories,
as it is needed by the the `sync` command.
Improves on #5175, provides a work around for #4907.
Change-Id: I30033614c1a2fad3f1363b85ff69cf92f697c255
PiperOrigin-RevId: 200543985
|
|
|
|
|
|
|
|
|
|
| |
To disambiguate:
- @foo refers to the external dependency @foo//:foo (as before this change).
- //@foo refers to the target //@foo:@foo (i.e. in the default workspace).
RELNOTES[NEW]: Allow @ in package names.
PiperOrigin-RevId: 200541716
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #5378.
$ find $(bazel-bin/src/bazel info install_base) -type f | wc -l
508
$ stat -c %s bazel-bin/src/bazel
115014201
The number of embedded files is now 508 and the binary size is ~115Mb.
RELNOTES: None.
Change-Id: I75e43a959e1201cc36718a9acd0af96e9506c7d4
PiperOrigin-RevId: 200539940
|
|
|
|
|
|
| |
This reduces our reliance on ProfilerTask.
PiperOrigin-RevId: 200538769
|
|
|
|
|
|
|
| |
These are no longer necessary since we don't pipe the subprocess stdout/stderr
through Bazel anymore.
PiperOrigin-RevId: 200534552
|
|
|
|
|
|
|
|
|
|
| |
Link currently finds no issues. This seems to be because the proper tag is "platform:windows" rather than the documented "multi-platform > windows".
The fix merely updates the text and link to "platform:windows".
Closes #5393.
PiperOrigin-RevId: 200533655
|
|
|
|
|
|
|
| |
Move the testing class to the tests tree. This is in preparation for
dismantling BuildView and merging the relevant parts into AnalysisPhaseRunner.
PiperOrigin-RevId: 200532794
|
|
|
|
|
|
|
|
|
| |
constraints.
Closes #5341.
Change-Id: Ib74e59fec48102469a5039e045e3f3d0e0d86d8c
PiperOrigin-RevId: 200526448
|
|
|
|
|
| |
RELNOTES:none
PiperOrigin-RevId: 200525022
|
|
|
|
| |
PiperOrigin-RevId: 200518973
|
|
|
|
| |
PiperOrigin-RevId: 200516863
|
|
|
|
|
|
| |
We could conceivably do some monkey-patching at server startup to make all lambdas act Serializable, but one step at a time.
PiperOrigin-RevId: 200509321
|
|
|
|
|
|
|
|
|
|
| |
constant.
This allows us to continue using lambdas in its definition.
This is a partial rollback of https://github.com/bazelbuild/bazel/commit/ed1e7594b23100f89755491f36e46886b4a51c8d, since the work done to class-ify things there is unnecessary once every instance is @AutoCodec-ed.
PiperOrigin-RevId: 200504678
|
|
|
|
|
|
| |
not serialized. Tag TestCompletionValue and any ActionExecutionValue coming from a NotifyOnActionCacheHit (i.e., tests) like that. To make such values really not shared, request the ActionExecutionValue from TestCompletionFunction as opposed to the ArtifactValue (propagating the unshareable bit up seemed like too much fuss, and I have a dream of getting rid of ArtifactValue anyway).
PiperOrigin-RevId: 200504358
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the output from composeTransitions is one of the input PatchTransitions, return it.
If it's a composed transition, make sure to wrap it in a class which respects equality.
Without this change, running the same RuleTransitionFactory on the same attribute and
target twice will produce two non-equal Dependencies which can't be deduplicated by
OrderedSetMultimap - no lambda is equal to any other instance of the same lambda.
RELNOTES: None.
PiperOrigin-RevId: 200472777
|
|
|
|
|
|
| |
RELNOTES: None.
PiperOrigin-RevId: 200471197
|
|
|
|
|
|
|
| |
Tag some static members with @AutoCodec.
Replace some lambdas with explicit functions or classes.
PiperOrigin-RevId: 200467500
|
|
|
|
|
|
|
| |
stdout/stderr.
RELNOTES: None
PiperOrigin-RevId: 200459354
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 200455297
|
|
|
|
|
|
|
| |
A minor serialization improvement. I'm planning to refactor this code
significantly, but wanted to get this in before I forgot.
PiperOrigin-RevId: 200453925
|
|
|
|
|
|
|
|
| |
and output groups.
* Make ctx a keyword argument so that we can more easily add more parameters in the future and eventually remove ctx.
PiperOrigin-RevId: 200453550
|
|
|
|
|
|
| |
package lookups to get Targets.
PiperOrigin-RevId: 200452642
|
|
|
|
|
|
| |
feature.
PiperOrigin-RevId: 200451804
|
|
|
|
|
| |
RELNOTES: None
PiperOrigin-RevId: 200446926
|
|
|
|
|
|
|
|
| |
on that future.
This allows NestedSet deserialization not to block on storage reads - in-progress deserializations are simply made a member of the NestedSets they produce.
PiperOrigin-RevId: 200440131
|
|
|
|
|
|
|
| |
of bazel info crosstool-configuration
RELNOTES: None.
PiperOrigin-RevId: 200437121
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the original intent was to provide better messaging, the truth is things
like ibtool and actool can error because of the state of CoreServices when
targeting anything other than macOS. It appears this attempt to validate
the sdk argument ends up succeeding in some cases, meaning it doesn't
fail quickly, it does a fair mount of work, which we promptly throw away
and still return the original error result.
Rather then trying to expand this into some even more completely retry logic
it seems better to back away from this attempted messaging instead.
Looking at at history the better messaging stems from why it was recommended
that folks also pass the SDK version along with the Xcode version, but we've
gone back to just saying specific the Xcode version, so need for this
improved messaging has also been reduced.
PiperOrigin-RevId: 200422952
|