This change introduces variable descriptors that describe the name, stack slot index, and source code stretch in which a variable is valid.
Activation frames in the stack trace now can enumerate the variables that are active in that frame.
Next step: fetch the value of variables from the stack.
Review URL: http://codereview.chromium.org//8992020
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@2671 260f80e4-7a28-3924-810f-c04153c831b5
- Introduce 3 kinds of snapshots (full, application script and messages)
- Added a dart API function to be used for generating an application snapshot
and for loading the script from an application snapshot.
Next step is to introduce special handling in the WriteTo and ReadFrom
snapshot functions for 'kind == Snapshot::kScript'
Review URL: http://codereview.chromium.org//8772061
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@2105 260f80e4-7a28-3924-810f-c04153c831b5
- the return types must be covariant or contravariant (an earlier version of the
guide specified contravariance only).
- the names of optional parameters must match in the same order (an earlier
version of the spec specified that any subset was allowed, no order required).
Review URL: http://codereview.chromium.org//8664015
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1898 260f80e4-7a28-3924-810f-c04153c831b5
External strings refer to character data in memory located outside of
the managed heap. This memory is considered to be owned by the
embedding application. To help with the management of external
memory, the virtual machine allows the embedding application to
register for a "death notice" when an external string object is
garbage collected. A death notice takes the form of a callback
invoked by the garbage collector with the address of the external
memory. Death notices will be implemented in the garbage collector by
future commit.
Review URL: http://codereview.chromium.org//8383029
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1679 260f80e4-7a28-3924-810f-c04153c831b5
Change the default value of --silent_warnings from true to false, so that
warnings are visible when legacy factory syntax is used.
In order to facilitate transition of libraries and user programs, legacy factory
syntax is still supported by 2 workarounds, but warnings are printed.
The first workaround allows the factory clause to omit the type
parameter list, which otherwise has to match exactly with the list of
type parameters in the factory class declaration.
The second workaround allows a factory method to omit the type
parameter list. In that case, the type parameter list of the enclosing
class is used instead.
Workarounds will be removed to enforce correct factory syntax at a later time.
Review URL: http://codereview.chromium.org//8585004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1595 260f80e4-7a28-3924-810f-c04153c831b5
--
Terminology change: invalid handles are now called error handles.
Unhandled exceptions used to be a kind of valid handle. Now they are
a kind of error handle.
For the Dart_Invoke* functions, this means that the standard
error-checking blob drops from two tests to one test and is
harder to mess up.
Many other Dart api functions (Dart_ToString, for example) previously
dealt with unhandled exceptions by turning them into terse error
messages. Now these functions preserve information about the
exceptions and generate better error messages.
Changed Dart_HandleMessage to return success/failure. It seemed to fit.
--
Details:
Dart_IsValid becomes Dart_IsError (negated sense).
Dart_GetError now knows how to print a stack trace semi-nicely.
Dart_ExceptionOccurred -> Dart_IsUnhandledException.
Renamed ApiFailure class to ApiError to fit better.
ApiError now has a "data" pointer that points to either an error
message string or to an unhandled exception object.
Documentation changes aplenty.
Review URL: http://codereview.chromium.org//8501034
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1470 260f80e4-7a28-3924-810f-c04153c831b5
This CL fixes the initializer evaluation order and brings the VM fully up to spec.
Constructors are executed in two phases: the initializer phase and the constructor body phase. An additional implicit parameter tells the constructor code whether to execute the initializer list or the body (or both).
If the super initializer call is not at the end of the initializer list, the super constructor has to be called twice. The arguments to the super initializer have to be evaluated and stored in temporary local variables. At the beginning of the constructor block, a second implicit super call is inserted.
If the super initializer call happens to be at the end of the list, none of this madness has to happen, except for the extra implicit parameter to the constructor.
Review URL: http://codereview.chromium.org//8440014
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@1102 260f80e4-7a28-3924-810f-c04153c831b5
require the introduction of a signature type cached in signature functions.
Support printing of the name of an instantiated signature type, e.g. print
'(int) => int' instead of '<T>(T) => T<int>'.
Avoid cycles when printing the name of illegal types during error reporting by
checking that the type is not being finalized.
Review URL: http://codereview.chromium.org//8289027
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@479 260f80e4-7a28-3924-810f-c04153c831b5
hausner@google.com