This is the same as 1d028eed8d (which
was reverted) except that it doesn't remove the old AST factory
constructors (which broke dev_compiler). The removal of old AST
factory constructors will be done in a follow-up CL so that if it
unexpectedly breaks any other clients we will be able to revert it
without reverting this CL.
R=scheglov@google.com
Review URL: https://codereview.chromium.org/2536373008 .
We are not going to have LibraryElement(s) for the new analysis driver.
The current approach: get known library sources, compute their elements,
import these elements does not work well when there is no analysis cache.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org/2532393008 .
This improves recovery time for change/undo from 300 ms to 200 ms for
analyzer + analysis_server + front_end.
_FilesReferencingNameTask does not degrade in any noticeble way, it is
still about 0-1 ms for this code base, as compared to 60 ms without
fixing runing time in the task or the scheduler.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/2540403002 .
The tests for which dartk is missing a compile-time error will run the precompiler on the result and will therefore have a different status entry (even though it is caused by dartk).
Review URL: https://codereview.chromium.org/2547523002 .
The observatory assets tarball would be different every time due to the
version string, which makes it compress to a different size. The size
changes would then move the program data around, making it much more
difficult to determine if dart builds of different revisions are
actually identical.
Google Analytics doesn't need to know the exact version numbers, it will
be fine to say they are bleeding edge builds of a particular version.
BUG=
R=whesse@google.com
Review URL: https://codereview.chromium.org/2540383003 .
To make it clear in the status file whether a crash (or other issues) are coming
from the dartk compiler or from the vm, this CL introduces new status file
markers which are the normal markers prefixed with Dartk (e.g. DartkCrash).
Furthermore this CL groups common failures
* compiler: dartk & dartkp
* runtime: vm & dart_precompiled
into shared status file blocks, thereby deduplicating failures (which removes around 500 lines).
R=vegorov@google.com
Review URL: https://codereview.chromium.org/2543973002 .
When I'm looking at the dynamic call profiles of an internal app test,
I see a bunch coming from the SDK itself. In fact, the top five most
common dynamic call sites are in the SDK.
This fixes four of them. (The fifth is in runUnary() in Zone, and I
don't think can be made typed yet.)
R=vsm@google.com
Review URL: https://codereview.chromium.org/2542723003 .
The test will fail with an error like the following, rather than proceed with an incorrect null value.
R=efortuna@google.com
Review URL: https://codereview.chromium.org/2540363002 .
TypeError: Cannot read property 'Unhandled ir.FunctionExpression (dynamic x) → dynamic => x' of null
Currently the presubmit script for 'git cl upload' will just warn the developer
that code is incorrectly formatted and asks whether to proceed. This makes
developers sometimes just ignore the warning and upload incorrectly formatted
C++ code.
This causes incorrectly formatted code to be committed to the repository and
will cause a presubmit warning/question for all developers afterwards.
This CL will therefore turn the warning into an error to ensure our c++ code is
always correctly formatted.
R=zra@google.com
Review URL: https://codereview.chromium.org/2525633002 .
The way runtime/platform/hashmap.h:HashMap was implemented so far did not allow
deleting elements while iterating over the map. If one iterated like this
HashMap::Entry* cursor = map.Start();
while (cursor != NULL) {
if (cond) {
map.Remove(cursor->key, cursor->hash);
}
cursor = map.Next(cursor);
}
Then the iteration `cursor` will skip elements. This is due to the fact that
`HashMap::Remove()` is left-rotating elements in certain cases and
`HashMap::Next()` will unconditionally advance to the next position in the
backing store.
PROBLEM IS: There was existing code which did remove elements while iterating
over a HashMap.
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2533303005 .
