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 .
The following happened:
A listening socket (ipv4, first-port) was created. Afterwards another
listening socket (ipv6, 0) is being created. We look up in the hashmap
if there is already a listening socket on port `0` (which is never the case).
So we create a new socket, the OS assigns the socket a random port
(which just happens to be `first-port` as well). Then we insert a new OSSocket
entry into the hashmap with key `first-port` (and set its `next` field to NULL).
This will simply override the existing entry.
During shutdown we loop over all (fd, OSSocket) pairs and try to remove
`OSSocket` from the port->socket map (via the linked `next` list). We cannot
find the `OSSocket` which we accidentally droped earlier, so we dereference
`0->next` and hit a SEGFAULT.
What should've happend is to correctly link the `OSSocket`s via the next field.
Fixes#27847R=asiva@google.com, fschneider@google.com
Review URL: https://codereview.chromium.org/2540013002 .
In kernel, library import URIs now support an "app" scheme as an
alternative to the "file" scheme, representing a path relative to
the application root.
dartk takes an --app-root flag giving the application root. If none
is given, file URIs are used instead.
The intention is that kernel binaries should not carry irrelevant
path information, such as the path to the home directory of the
user who compiled a given file.
It is not the intention that end-users should see an app URI.
Import paths are currently not shown to users at all, and if we need
to do this, they should be translated to file paths first.
In theory we could stick to file URIs with relative paths, but the Uri
class from dart:core makes this difficult, as certain operations on it
assume that file paths should be absolute.
Source mapping URIs are not yet affected by this change.
R=kmillikin@google.com
Committed: 60adb852ad
Review URL: https://codereview.chromium.org/2532053005 .
Reverted: bb540416f2
