References to loadLibrary on a library prefix are compiled to a
helper function that returns a Future that always completes
successfully.
The deferred libraries aren't actually deferred, but code that uses
loadLibrary() now doesn't barf.
BUG=#27343
R=vsm@google.com
Review URL: https://codereview.chromium.org/2477673006 .
It shouldn't matter, but for some streams (e.g., a `ReceivePort`)
it does make a big difference whether it's closed or not.
We can't make a port not keep the isolate alive unless it has been listened to.
If we could, this wouldn't be necessary.
R=floitsch@google.com
Review URL: https://codereview.chromium.org/2481083003 .
It works for top-levels, fields, locals, prefixed expressions.
Integration is not the most efficient - we resolve the full unit.
It works fine for files with about 1000 lines, about 50-70 ms.
We could slightly improve timing if we prioritize completion over
navigation and highlight notifications, which are currently prepared
and sent before completion.
In giant files like src/dart/element/element.dart, about 8500 lines,
it takes about 400 ms from typing to receiving completion. The theoretical
bottom bound for such files is about 70 ms - time that it required to
parse, create unlinked bundle, ensure that the API signature is the
same, load linked bundles and prepare to resynthesize. On top of this
goes any time required to resolve a single method and completion itself.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/2478963002 .
Previous to this change, ResolveUnitTypeNamesTask would set types to
`dynamic` if there was no explicit type in the source code, and
InferInstanceMembersInUnitTask would overwrite those types with
inferred types. This caused a problem if the result of
ResolveUnitTypeNamesTask got flushed due to memory pressure, but the
result of InferInstanceMembersInUnitTask did not. In that case, the
task model would come back at a later time and re-run
ResolveUnitTypeNamesTask, causing the inferred types to be set back to
`dynamic`. But it would not re-run InferInstanceMembersInUnitTask.
As a result, the inferred type would be lost. This manifested as a
sporadic failure to inferred types in analysis server. Annoyingly,
edits to the file(s) involved would frequently cover up the problem
(temporarily) since they would invalidate the cache entries, forcing
the task model to re-run both tasks.
This CL fixes the problem by adding _declaredType and
_declaredReturnType fields to the element model;
ResolveUnitTypeNamesTask writes to those.
InferInstanceMembersInUnitTask continues to write to _type and
_returnType, as it always has. When a type or return type is
requested from the element model, the getter consults _type (or
_returnType) first; only if it is null does it fall back to
_declaredType (or _declaredReturnType).
This gives us the behavior we need (inferred types override the
implied "dynamic" type stored by ResolveUnitTypeNamesTask), but since
the two tasks are now writing to different fields in the element
model, it is now safe to re-run ResolveUnitTypeNamesTask--it will no
longer overwrite the inferred types.
Fixes#27482.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2480783003 .
This makes the benchmark below to run in 100 ms, vs. 250 ms.
main() {
var bytes = new Uint8List(16);
for (int i = 0; i < 2000; i++) {
var timer = new Stopwatch()..start();
ApiSignature signature = new ApiSignature();
for (int i = 0; i < 1000; i++) {
for (int i = 0; i < 1500; i++) {
signature.addBytes(bytes);
}
}
timer.stop();
print('time: ${timer.elapsedMilliseconds}');
}
}
R=paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/2474993004 .
The current implementation listens to the stream and waits for it to complete.
The change makes it listen and then immediately cancel, and then return a
subscription that only sends done.
R=floitsch@google.com
Review URL: https://codereview.chromium.org/2444363004 .
