| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
This enables both native and Skylark rules to declare attributes which
have labels/Targets as keys, and have string values.
--
PiperOrigin-RevId: 148365033
MOS_MIGRATED_REVID=148365033
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
targets.
These two functions don't use a Uniquifier internally so if the same bzl file foo.bzl is loaded multiple ways in 'e' in 'loadfiles(e)' then 'f' in 'f(loadfiles(e))' will observe foo.bzl multiple times.
This isn't observable in practice (i.e. I cannot write a black-box query test that would fail without this CL) because:
(1) BlazeQueryEnvironment#eval(QueryExpression, VariableContext<Target>, Callback<Target>) uses an intermediate aggregating callback and thus doesn't use the streaming query evaluation model. This means that the internal deduping in BlazeQueryEnvironment#getBuildFiles is sufficient.
(2) SkyQueryEnvironment uses an outer BatchStreamedCallback which internally uses a Uniquifier.
Still, this CL is useful for SkyQuery because without we're doing wasted work (e.g. in my example above, 'f' will wastefully do duplicate work with the .bzl files from the inner loadfiles(e)) because the deduping happens on the final query result, not on the intermediate result from 'buildfiles'/'loadfiles'.
For 'buildfiles', there's an additional wart with (1) above because FakeSubincludeTarget doesn't override Object#equals/hashCode.
--
PiperOrigin-RevId: 147656183
MOS_MIGRATED_REVID=147656183
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 147621296
MOS_MIGRATED_REVID=147621296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This overrides the traditional has(String name, Type<>T> type)
with has(String name) and removes the type check outright from
isConfigurable.
Ideally we'd remove the old version in this same change. But there
are enough uses of it that that's not a risk-free change and
is safer as followup changes.
--
PiperOrigin-RevId: 147513593
MOS_MIGRATED_REVID=147513593
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The name attribute gets special treatment in the codebase, in that
it's not simply yet another attribute but stored in it's own field.
Thus, every callside dealing with attributes needs to be aware of
this special case and explicitly handle the name attribute. It's
easy to see that this can lead to bugs. For example, querying for
the name attribute is currently broken due the querying code not
being aware of the special case [1].
Discussions with experienced bazel developers came to the conclusion
that there is no need (anymore) to treat the name attribute specially
and thus we decided it's best to remove the special treatment and
handle the name attribute as any other attribute.
This change removes the handling of name attributes and also adds a test
case to verify that bug [1] is fixed.
[1] https://github.com/bazelbuild/bazel/issues/278
--
PiperOrigin-RevId: 147446345
MOS_MIGRATED_REVID=147446345
|
|
|
|
|
|
|
|
|
|
| |
I was trying to simplify GenQuery, and found this during an audit of the
code; it's not sufficient to make any larger changes, but it may help
eventuall.
--
PiperOrigin-RevId: 147023626
MOS_MIGRATED_REVID=147023626
|
|
|
|
|
|
|
|
|
|
| |
Two of the functions are never used, several of the parameter are not
used or can be simplified (require callers to convert from Target ->
Label).
--
PiperOrigin-RevId: 146787380
MOS_MIGRATED_REVID=146787380
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 145473478
MOS_MIGRATED_REVID=145473478
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because the event handler's inner handlers are removed after each query
command, caching the handler caused a subset of subsequent commands'
errors (those reported through the resolver's handler) to go unlogged.
Also fix a bug with cycle detection in DelegatingWalkableGraph.
--
PiperOrigin-RevId: 145124271
MOS_MIGRATED_REVID=145124271
|
|
|
|
|
|
|
|
| |
WalkableGraph#getException to be given non-existent keys without crashing. Add WalkableGraph#isCycle to fill the gap in testing for the difference between non-existence and depending on a cycle.
--
PiperOrigin-RevId: 143205289
MOS_MIGRATED_REVID=143205289
|
|
|
|
|
|
|
|
|
| |
This used to be how test_suites depended on other test_suites.
Now they just go in "tests".
--
PiperOrigin-RevId: 142607603
MOS_MIGRATED_REVID=142607603
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Investigating if causes deadlock/thread starvation.
--
PiperOrigin-RevId: 142575769
MOS_MIGRATED_REVID=142575769
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 142295816
MOS_MIGRATED_REVID=142295816
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(i) Use a CountDownLatch in ParallelQueryUtils#executeQueryTasksAndWaitInterruptibly to avoid busy-looping while waiting for query subtask completion (this busy-looping unnecessarily ties up a thread). But we still retain the fail-fast semantics we want (I renamed the method to emphasize this).
(ii) Also have a special-case in ParallelQueryUtils#executeQueryTasksAndWaitInterruptibly for evaluating one query subtask so we don't wastefully use another thread.
(iii) Also add ThreadSafety annotations to ParallelQueryUtils.
----
(i) and (ii) combine to address the following theoretical issue. Suppose we're evaluating a query expression of the form "(e1 - e2) + (e3 - e4)". The old code would (with the worst-case FJP thread scheduling) have the following threads at the _same_ time:
Main QueryCommand thread - executeQueryTasksAndWaitInterruptibly(queryTasks = [(e1 - e2), (e3 - e4)]
FJP thread - executeQueryTasksAndWaitInterruptibly(queryTasks = [e2])
FJP thread - eval(e2)
FJP thread - executeQueryTasksAndWaitInterruptibly(queryTasks = [e4])
FJP thread - eval(e4)
So of those 5 concurrent threads, 3 would be doing busy-loop waiting. For more pathological query expressions, we could end up tying up lots of threads doing wasteful busy-loops.
--
PiperOrigin-RevId: 142215680
MOS_MIGRATED_REVID=142215680
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 141920696
MOS_MIGRATED_REVID=141920696
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 141904124
MOS_MIGRATED_REVID=141904124
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turns out that ForkJoinTask#adapt(Callable) returns a ForkJoinTask whose Future#get on error throws a ExecutionException wrapping a RuntimeException wrapping the thrown checked exception from the callable. This is documented behavior [1] that I incorrectly didn't know about.
The additional level of wrapping meant that the catch-block of the parallel implementation of BinaryOperatorExpression wasn't rethrowing the InterruptedException/QueryException that the parallel task threw.
The subtly in this bug is that the query expression being evaluated needs to be of the form "e1 + e2", where evaluation of "e1" throws a QueryException even in keepGoing mode (note that most of the query errors actually go through AbstractBlazeQueryEnvironment#reportBuildFileError). The test I wrote picks on LetExpression's evaluation-time (rather than e.g. parsing time) validation of the variable name.
[1] https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinTask.html#adapt(java.util.concurrent.Callable)
--
PiperOrigin-RevId: 141772584
MOS_MIGRATED_REVID=141772584
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 141307853
MOS_MIGRATED_REVID=141307853
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 141178325
MOS_MIGRATED_REVID=141178325
|
|
|
|
|
|
|
|
| |
ensure that all of e1, e2, ..., and eK are elligble for parallel evaluation. This is _not_ the same as providing a parallel implementation of f, which we can do separately in followup CLs.
--
PiperOrigin-RevId: 140861694
MOS_MIGRATED_REVID=140861694
|
|
|
|
|
|
|
|
|
|
|
| |
for concurrent visitations.
During BFS visitation of rdeps and rbuildfiles, it uses a centralized pool
(backed by a LinkedBlockingQueue) to store all pending visits, and a
periodically running scheduler to schedule tasks for each pending visit.
--
MOS_MIGRATED_REVID=140398162
|
|
|
|
|
|
|
| |
equivalence to "e1 - (e2 + e3)" and the fact that we already have a parallel implementation of "e2 + e3".
--
MOS_MIGRATED_REVID=139792288
|
|
|
|
|
|
|
| |
'buildfiles(e)'.
--
MOS_MIGRATED_REVID=139787078
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=139613681
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=139508838
|
|
|
|
|
|
|
|
|
| |
SkyQueryEnvironment#beforeEvaluateQuery if possible to save on latency for small queries.
This assumes that if the graph is up to date, then the data in SkyQueryEnvironment is also up to date. It also assumes that a ForkJoinPool remains usable until #shutdownNow is called.
--
MOS_MIGRATED_REVID=139386363
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=139357569
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=139113333
|
|
|
|
|
|
|
| |
by introducing TargetPattern#parEval, which allows TargetPatterns' evaluations to explicitly have parallel implementations (no need to secretly use a FJP).
--
MOS_MIGRATED_REVID=139101922
|
|
|
|
|
|
|
| |
final fields.
--
MOS_MIGRATED_REVID=138894804
|
|
|
|
|
|
|
| |
expensive parallel operations can operate on at once.
--
MOS_MIGRATED_REVID=138779172
|
|
|
|
|
|
|
| |
the scope and the parser prefix, both of which are final, it never changes.
--
MOS_MIGRATED_REVID=138536185
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=138534021
|
|
|
|
|
|
|
|
| |
No need for the char[] in the middle, prevents us from accidentally modifying
input, or sucking up ram on huge queries.
--
MOS_MIGRATED_REVID=137872573
|
|
|
|
|
|
|
|
|
| |
- Extend https://github.com/bazelbuild/bazel/commit/83ffb5e7bc034ea2dd1e957249079b3884a9450d to --output=xml, --output=proto, too. This makes query much more resilient against freezing / OOMing from "select() + select() + select() + ..." patterns.
- Make the above logic accessible to any output type.
- Move AggregatingAttributeMapper.flattenAttributeValues to ProtoOutputFormatter, since this is really a utility method for ProtoOutputFormatter.
--
MOS_MIGRATED_REVID=137429116
|
|
|
|
|
|
|
| |
evaluation: put the outputting of targets before the recursive visitation. Since ForkJoinTasks are fork'd in order, the new order optimizes for throughput to the underlying Callback.
--
MOS_MIGRATED_REVID=137281325
|
|
|
|
|
|
|
|
| |
attr = select({"a": LABEL_LIST, "b": LABEL_LIST, ...}). This can be
exponential (w.r.t. the # of select conditions) and produce OOMs.
--
MOS_MIGRATED_REVID=137200979
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=137192333
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=137064426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Reason for rollback ***
Roll-forward with fix.
Tested with `bazel build src:srcs //src/test/...` using a bootstrapped bazel.
Fixes #1923.
RELNOTES[INC]: Non test-only targets can no longer depends on test-only targets.
*** Original change description ***
Automated [] rollback of commit a9f20b0d6459d395444c45cf5e94a899f3443633.
*** Reason for rollback ***
Broke Bazel CI:
ERROR: /home/ci/workspace/Bazel/JAVA_VERSION/1.8/PLATFORM_NAME/linux-x86_64/src/BUILD:284:1: in filegroup rule //src:srcs: non-test target '//src:srcs' depends on testonly target '//src/java_tools/junitrunner/java/com/google/testing/junit/junit4:srcs' and doesn't have testonly attribute set.
ERROR: Analysis of target '//scripts/packages:packages' failed; build aborted.
http://ci.bazel.io/view/Bazel%20b...
***
--
MOS_MIGRATED_REVID=136589937
|
|
|
|
|
|
|
| |
into batches. This way nodes corresponding to targets in the same package are likely to be in the same batch.
--
MOS_MIGRATED_REVID=135684088
|
|
|
|
|
|
|
|
|
| |
them in ParallelSkyQueryUtils.
In AllRdepsUnboundedVisitor#getVisitResult, only get rdeps of the nodes in question. As long as we're careful to only visit nodes have corresponding Targets (which we already are doing), there's no need to also get the Targets corresponding to the nodes in question.
--
MOS_MIGRATED_REVID=135680956
|
|
|
|
|
| |
--
MOS_MIGRATED_REVID=135495077
|
|
|
|
|
|
|
| |
overrides. Also, have AbstractBlazeQueryEnvironment#evaluateQuery take an OutputFormatterCallback instance rather than a Callback instance. This is more sensible since the latter is only intended to be used intra-query, while the former is intended for usage in end-to-end query evaluation. This lets us slightly simplify QueryCommand, by shifting the responsibility for managing the OutputFormatterCallback to AbstractBlazeQueryEnvironment#evaluateQuery.
--
MOS_MIGRATED_REVID=134827588
|
|
|
|
|
|
|
| |
Fixes #1863
--
MOS_MIGRATED_REVID=134767527
|
|
|
|
|
|
|
|
| |
Usually an OutputStream will do. Forgo the extra layer of indirection and
stream directly to the output.
--
MOS_MIGRATED_REVID=134682243
|
|
|
|
|
|
|
| |
shared naive BFS implementation. Also implement RegexFilterExpression#parEval.
--
MOS_MIGRATED_REVID=134598046
|
|
|
|
|
|
|
|
|
|
|
| |
Instead have SkyQueryEnvironment#evaluateQuery be responsible for handling cleanup of its internal ForkJoinPool.
In addition to being a more sensible way of organizing the code (imo, it makes sense for SkyQueryEnvironment to clean up after itself), this fixes several issues:
(i) If query evaluation is interrupted, the AbstractBlazeQueryEnvironment#close call at the end of the try-with-resources statement in QueryCommand would be blocking and non-urgent. N.B. This was not an issue with the current ForkJoinPool usage, but was an issue with the old ThreadPoolExecutor usage.
(ii) Because of how the code in QueryCommand was structured, OutputFormatterCallback#close would happen _before_ the AbstractBlazeQueryEnvironment#close call. If query evaluation is interrupted, threads executing query tasks may be invoking the callback after the callback had been shut down!
--
MOS_MIGRATED_REVID=134573395
|
|
|
|
|
|
|
| |
evaluation in SkyQueryEnvironment. FJP is nicer to program against, imo.
--
MOS_MIGRATED_REVID=133844508
|
|
|
|
|
|
|
| |
FIXED=31439098
--
MOS_MIGRATED_REVID=133751771
|