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
This code was failing when analyzing dev_compiler with the new driver.
var instanceVarArrowExpression = (f) async => await f;
The reason was that we:
1. Don't understand AwaitExpression in AbstractConstExprSerializer.
2. So, we throw StateError.
3. So, AbstractConstExprSerializer.serialize() marks isValidConst.
4. But we don't check 'isValidConst' in linker.
5. The list of operations is empty, so we don't have anything in stack.
6. So, we throw an exception in linker.
R=paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/2541603002 .