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 .
This should help least-upper-bound computations to not think of EfficientLength
as completely separate from Iterable even though they are always used together.
It doesn't solve all problems with the least-upper-bound computation,
but at least some of the more often occuring ones.
R=floitsch@google.com
Review URL: https://codereview.chromium.org/2467113003 .
Committed: b08fb1373f
This breaks inlining because it expects that all collected ReturnInstr
are strongly connected to the rest of the graph.
Source based FlowGraphBuilder achieves that by eagerly stopping construction
as constructed fragment is closed (e.g. Throw is emitted).
R=kustermann@google.com
BUG=
Review URL: https://codereview.chromium.org/2528673002 .
- Kernel-to-IL translation leaves behind some unused constants without temp indices assigned.
- Let compile time errors propagate instead of failing with FATAL error in the post load class finalization.
R=kustermann@google.com
BUG=
Review URL: https://codereview.chromium.org/2528763002 .
E.g.
file1:
------------
library crash;
part "file2.dart";
main() {
print(field2);
}
crash() {
try {
throw "Crashing!";
} catch(exception, stacktrace) {
print(stacktrace);
}
}
file2:
------------
part of crash;
var field2 = crash();
We want something like
#0 crash (whatnot/file1.dart:11:5)
#1 field2 (whatnot/file2.dart:3:14) <-- good line
#2 field2 (whatnot/file2.dart:3:5)
#3 main (whatnot/file1.dart:6:9)
and not like
#0 crash (whatnot/file1.dart:11:5)
#1 field2 (whatnot/file1.dart:3:14) <-- bad line
#2 field2 (whatnot/file2.dart:3:5)
#3 main (whatnot/file1.dart:6:9)
R=kmillikin@google.com
Review URL: https://codereview.chromium.org/2519133004 .
- Some DBC tests (regexp, field guards) was turned on inadvertantly
- Skip cc/Profiler_InliningIntervalBoundry on release builds
(need to figure how to handle the inlining difference between
debug/release builds)
BUG=
Review URL: https://codereview.chromium.org/2528793003 .
Install a signal handler in the standalone VM that dumps a backtrace
similar to what we already do on assertion failures.
For now only Linux and MacOS are supported.
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org/2514113002 .
- Remove CheckConnect.
- Enable NODELAY.
- Add testSimpleReadWriteClose to hello_fuchsia_test.
Add stub implementation of OS::MaxRSS so Observatory can load without crashing the target VM.
R=asiva@google.com
Review URL: https://codereview.chromium.org/2523133002 .
