Also converts the API to use intptr_t instead of a mixture of int64_t and int. Internally all variable length objects have lengths and maximum values represented as intptr_t (actually Smi ranges). In order to check for these maximum lengths we need to have a common type for 32 and 64 bit platforms.
Helping constructs like IOBuffer can still use 64bit lengths, but have to check that there values are actually in the domain of intptr_t as soon as internal objects are created.
Addresses issue 4314.
BUG=
R=asiva@google.com, sgjesse@google.com
Review URL: https://codereview.chromium.org//23532048
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27395 260f80e4-7a28-3924-810f-c04153c831b5
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
The print-ast output is useful for debugging front end issues. It is a mix
of fully-parenthesized prefix notation (i.e., Lisp S-expressions) with some
infix.
It is not valid S-expressions for various other reasons. Most obviously, it
uses ' (single quote) instead of " (double quote) to delimit strings.
This change makes the print-ast output a valid Scheme S-expression. It can
be pretty printed by copying it, quoting it (by preceding it with a single
quote), and evaluating it at the REPL of a Scheme implementation.
Also, the AST node pretty names are changed to predictably match the class
name. It doesn't seem helpful to have them be arbitrary.
BUG=
R=regis@google.com
Review URL: https://codereview.chromium.org//23923005
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27282 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
Removing an old, Dash-era hack that makes 2is a faulty number
literal rather than the number 2 followed by the identifier or
keyword "is".
Also fix number_identifier_test.dart which contains an access
to a non-existent getter "memberName" of class NoSuchMethodError.
Review URL: https://codereview.chromium.org//23711004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27216 260f80e4-7a28-3924-810f-c04153c831b5
Instead of having a separate IL instructions relational comparisons
are built as normal instance calls initially. When optimized, we replace
the instance call with a smi/double/mint comparison instruction.
This enables generic inlining of relational operator calls and simplifies
code generation, too.
Merging comparisons with branches is done in the optimizing compiler's
branch simplification phase.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//23757016
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27058 260f80e4-7a28-3924-810f-c04153c831b5
The IsPowerOfTwo function is used together with ShiftForPowerOfTwo. Both function
do not work with zero. This caused the optimizing compiler to generate invalid code
for the expression
x ? 0 : 0
where it assumed that if one of the constants is a power-of-two, it can
be computed by (1 << n). We check for 0 in a number of places, but instead
I decided to fix Utils::IsPowerOfTwo itself and remove unnecessary checks
for the zero case.
TEST=tests/language/vm/if_conversion_vm_test.dart, runtime/vm/utils_test.cc
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//23604024
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@27033 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
mlippautz@google.com