Update VM to latest spec. Referencing a name that is imported
from more than one library is no longer a compile-time error.
If one of the sources of an ambiguous reference is a dart library,
the dart library declaration is automatically hidden.
Also fixes a bug where looking up a getter name in a library
found the getter even though the name is filtered out in the
'hide' combinator.
Long-term we should fix the need for repeatedly convert between
the mangled getter and setter names and the untangled name.
Fixes 12915, 12913, 12724.
R=regis@google.com
Review URL: https://codereview.chromium.org//23484020
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27312 260f80e4-7a28-3924-810f-c04153c831b5
This CL is the first step in enabling full inlining of == calls.
Previously, calls to any function with the name "==" were not considered
for inlining because super-calls were not handled correctly. Instead
of implementing == semantics for super calls in the back-end, the parser
now expands super calls to == into
let t1 = left, t2 = right {
(t1 === null || t2 === null) ? t1 === t2
: static_call(super.==, t1, t2)
}
This change removes a bit of platform-specific assembly. Normal instance calls
to == are still translated as before. Expanding those at the AST level would
incur a too high cost in terms of (unoptimized) code size, and also would be
an obstruction for optimizations of equality. The plan is to expand those
only at optimization time if there is an inlineable instance call to ==.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//23627009
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27248 260f80e4-7a28-3924-810f-c04153c831b5
The Name function is used for pretty printing except that for a few
node types we rely on a specific name for implementation correctness.
Overriding the pretty printing function to get out a type name, or a
variable name, or an operator symbol name, is risky.
1. Code that relies on the semantics of the name will break if the
pretty name is changed.
2. Pretty printing is less useful. For instance, LoadLocalNode just
prints the variable name (twice, once as the AST constructor and
once in quotes as the variable name). This is confusing if the
variable happens to have the same name as one of the other pretty
names, e.g., args or seq.
Now, there is a virtual function to get the pretty name but classes do
not change it to communicate other information (type names, variable
names, operator names).
BUG=
R=regis@google.com, srdjan@google.com
Review URL: https://codereview.chromium.org//23960003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27244 260f80e4-7a28-3924-810f-c04153c831b5
My previous approach was not enough, since methods can
be invoked via reflection before they are parsed/compiled.
This CL fixes the problem at hand, but I'd like a more general
approach to mark those methods. Maybe an annotation at the declaration
would be better.
I also refactored the test case as suggested in the previous code review.
R=srdjan@google.com
Review URL: https://codereview.chromium.org//23458008
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27009 260f80e4-7a28-3924-810f-c04153c831b5
Add test.
Update status files.
Explanation of change: A malbounded type argument should not be mapped to
dynamic, as is a malformed type argument.
This change also adds a bunch of TODOs related to the encounter of malbounded
types in unexpected places.
A follow-up change will address these TODOs, add more tests, and may simplify
code that is still handling malformed types where they cannot occur anymore
after the spec simplified their handling.
R=hausner@google.com, srdjan@google.com
Review URL: https://codereview.chromium.org//23190035
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@26665 260f80e4-7a28-3924-810f-c04153c831b5
The optimizing compiler currently recognizes a certain frequent native methods
like array length or string length and provides an inlined implementation.
Inlining does currently not work for polymorphic call sites of these methods.
This CL enables also polymorphic inlining in the case of .length getters for
arrays and strings.
1. The method is recognized at flow graph build time. The builder creates
the body of the method for both compilers (non-optimizing and optimizing).
Native methods that are not recognized, are translated as before using a NativeCall
IL instruction.
2. The flow graph inliner handles recognized methods in the same manner as normal methods.
Until now intrinsic and recognized method could not be inlined. This CL enables it.
3. There is no need for an intrinsic assembly implementation because recognized methods
have an IL implementation that does not call into the C++ runtime. I left the intrinsics
in for now, but they can be removed if there is not noticable performance benefit anymore.
4. The inlining heuristics are tweaked in a way that enables more aggressive inlining
of recognized methods: +1 level of inlining depths, call sites of recognized methods are
not counted in the inlining heuristic.
R=kmillikin@google.com, srdjan@google.com
Review URL: https://codereview.chromium.org//22839003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@26429 260f80e4-7a28-3924-810f-c04153c831b5
When nesting try-finally, the outer finally was incorrectly executed
twice under certain conditions (a return in the inner try-block and a outer
finally-block that ends with throw)
This was because finally-code was inlined at return/break/continue statements
and it was associated with the wrong catch-handler when compiling.
This CL tracks indices of try-blocks in the parser so that each inlined
finally block has the correct catch handler index.
BUG=https://code.google.com/p/dart/issues/detail?id=11972
TEST=test/language/throw8_test.dart
R=hausner@google.com
Review URL: https://codereview.chromium.org//22184003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@25767 260f80e4-7a28-3924-810f-c04153c831b5
Until now there was a large discrepancy between
x.f() and
(x.f)()
This CL makes x.f() as fast as (x.f)() by automatically
generating a intermediate dispatcher function that loads
the field and invokes the result as a closure.
The approach resembles the one taken for fast noSuchMethod
invocation and reuses the same per-class cache
of dispatcher functions.
It also fixes a bug in the debugger so that VM-generated
implicit dispatcher functions (like for noSuchMethod, or
field-as-method invocation) don't show up the debuggers
stack trace.
BUG=https://code.google.com/p/dart/issues/detail?id=11041R=srdjan@google.com
Review URL: https://codereview.chromium.org//18750004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@25001 260f80e4-7a28-3924-810f-c04153c831b5
hausner@google.com