- make Dart2 the default option for the command line VM
- add option --no-preview-dart-2 as a fallback option to run dart1
- change test scripts to use the executable dart for testing dart2 mode instead of
pkg/vm/tool/dart2
- adjust numerous build and test configurations
Change-Id: Id813fa5b71a89c7ec9335d3f6e83cfc9f35f86e7
Reviewed-on: https://dart-review.googlesource.com/58240
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
In most cases the correct fix is to simply drop the generic comment
syntax (e.g. replace "List/*<Map>*/" with "List"). We can't use the
more precise type because the runtime type is actually more general
(e.g. when processing an object that came from the JSON parser, all
lists have runtime type List<dynamic>, even if their elements happen
to be uniform). But we can introduce more precise types when handling
substructures.
Exception: all JSON-derived maps have type Map<String, dynamic> (since
JSON maps always have string keys), so we can use a more precise type
when dealing with JSON maps.
Change-Id: I48c9dbdda97c11530978212146f74db7b43f5197
Reviewed-on: https://dart-review.googlesource.com/58320
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
If there is registered expression compiler, VM debugger uses it to compile expressions. Otherwise, it will fallback to use kernel service compiler.
This is needed to support Flutter use case where compiler is running on developer's host machine, not on the device where VM is running.
Bug: dartbug.com/31981
Change-Id: I8bdfc8ab45a57c306169abe189f1e24e1b0bcf40
Reviewed-on: https://dart-review.googlesource.com/57520
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This CL adds base classes for breakpoint events (which support a
`breakpoint` getter) and async suspension events (which support an
`atAsyncSuspension` getter). Previously these getters were accessed
through dynamic dispatch.
Change-Id: I9bc450a8988483cd0662b1dfe31b4adaf0936ff9
Reviewed-on: https://dart-review.googlesource.com/57380
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is necessary because HtmlElement.children= requires its parameter
type to be a List<Element>, and text nodes are not elements.
Change-Id: I99c91fe060c16f02d737d904f6869b3dad19c196
Reviewed-on: https://dart-review.googlesource.com/57005
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes#33170: We had an assert that type variables are not bounded by "dynamic".
This assert was previously valid because the FE replaces "extends dynamic" with
"extends Object". However, it's not necessary in any way, and it's difficult to
access the Object type from outside the FE when synthesizing type parameters for
expression compilation.
Fixes#33171: The synthetic class generated during serialization to hold the
synthetic method may need to extend core library classes if the expression's
scope was within a core library class. In this case, the class finalizer needs
to avoid applying the restrictions on class extension to the synthetic class.
To facilitate this, we now use a single class name for all synthetic classes,
rather than copying the original class name. The name of the synthetic class has
no function at all, since the synthetic method is reparented to the original
class before execution.
Fixes#33239: The arguments descriptor passed to InvokeFunction for expression
functions which capture generic type parameters was using the wrong argument
count.
Fixes#33270: Use LookupClassAllowPrivate instead of LookupClass when resolving
the expression's scope in the VM.
Test Plan:
#33170: python tools/test.py -m debug -c dartk --strong service/evaluate_function_type_parameters_test
#33171: python tools/test.py -m debug -c dartk --strong service/eval_test
#33239: Updated "evaluate_function_type_parameters_test.dart".
#33270: Updated "eval_test.dart".
Change-Id: I376926bddd2224ec2322b43685d6c13831f1a8e7
Reviewed-on: https://dart-review.googlesource.com/56060
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
The method ObservatoryApplication._switchVM calls newVM.onDisconnect
and requires the resulting future to be completed with a String. In
normal operation, this is satisfied and we just need to change a few
static types to enforce it. But when FakeVM was in use, the future
was completed with `this`. Since ObservatoryApplication._switchVM is
the only call site that cares what the future is completed with, it
makes sense to just change all the types to Future<String> and modify
FakeVM accordingly.
Change-Id: Id94d27ac6a42f31ab19ccc9ad8dd270ecf4042b4
Reviewed-on: https://dart-review.googlesource.com/57400
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Add a clause indicating that FunctionCallTreeNode (in
lib/src/sample_profile/sample_profile.dart) implements
M.FunctionCallTreeNode. This allows the two types for `root`
inherited by FunctionCallTree to be consistent with each other: the
type inherited from CallTree<FunctionCallTreeNode> is
FunctionCallTreeNode whereas the type inherited from
M.FunctionCallTree is M.FunctionCallTreeNode.
Change-Id: I0b48c57f84681a7d40afadfb59c72501cfe38577
Reviewed-on: https://dart-review.googlesource.com/57002
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This splits create_archive.py into two steps. One that creates the .tar
and one that creates the .cc for the .tar. This way on Fuchsia, the
second step will take the prebuilt instead of building it.
Change-Id: I7f407f9e70db3135884eeeb61aa5aec3091f1fcc
Reviewed-on: https://dart-review.googlesource.com/56291
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Since the downcast is explicit (using "as") the type will be checked
even in unchecked mode, so technically there is a slight risk of
breakage. But since the callback is so near the creation of the
ButtonElement, I'm not concerned. Also, I'm not concerned about the
performance penalty of the explicit downcast because the cost is only
paid once per user click.
Change-Id: I64fbb442985f6ba6f745f665b36a3321498025e4
Reviewed-on: https://dart-review.googlesource.com/56704
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
For brevity we explicitly downcast the parameter type (using "as")
rather than implicitly downcasting it (by assigning to a fresh
variable). Since this is test code, I'm not concerned about the
performance penalty of the explicit downcast.
Change-Id: I2bf1556ec11db124978c6631df8fcdd5adbc298d
Reviewed-on: https://dart-review.googlesource.com/56701
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In some cases we need to specify a type because the inferred type
would be too specific. For example, in the code:
final content = [new SampleBufferControlElement(...)];
...
content.addAll([new BRElement(), ...]);
Strong mode would infer a type of `List<SampleBufferControlElement>`
for `content`, making it impossible to add other kinds of HTML
elements to the list later. So we have to specify explicitly that the
list element type is meant to be `HTMLElement`.
In other cases we need to specify a type because the inferred type is
too general. For example, in the code:
Future<List<String>> complete(...) {
var result = [];
...add values of type String to `result`...
return new Future.value(result);
}
Strong mode would infer a type of `List<dynamic>` for `result`, making
it impossible to enclose in a `Future<List<String>>`. So we have to
specify explicitly that the list element type is meant to be `String`.
Change-Id: I1b1c884529de2775898dfff800d250cd10629811
Reviewed-on: https://dart-review.googlesource.com/56700
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL makes the following changes, which should be safe since they
don't affect Dart 1.0 semantics:
- Explicitly declare the types of certain variables as `dynamic` to
avoid strong mode inferring a type that leads to errors.
- Explicitly cast certain expressions to `dynamic` to allow access to
members that are dynamically known to be present.
- Add `covariant` annotation to method parameters that are a subtype
of the corresponding parameter in the base class.
Change-Id: Ibefe4d9591f70ea954373ca4d521bc54179cca9b
Reviewed-on: https://dart-review.googlesource.com/55900
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This CL addresses a code pattern where a method expects its parameter
to have a certain type, but that method is torn off and passed as a
callback to another method expecting its parameter type to be more
general. For example:
void f(int i) { ... }
void g(void callback(Object o)) { ... }
void h() {
g(f); // Error: () -> int is not a subtype of () -> Object
}
This is a strong mode error because the type system cannot guarantee
that the value pased to f will be an int. The solution is to broaden
the type of the callback parameter so that it matches the type
expected for the callback. In most cases, we insert an implicit
downcast (by reassigning the parameter to a local variable with the
expected type), which in Dart 2.0 semantics will result in a runtime
check (similar to what happens in Dart 1.0 checked mode).
Since the downcasts are implicit, the Dart 1.0 semantics are
unchanged, so this should be a safe change.
Change-Id: I9583ea194343b89b39305c9796cfad299a47943f
Reviewed-on: https://dart-review.googlesource.com/55907
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
With this change debugger requests yield(await) positions from kernel builder so it can confirm which frame handles what exceptions.
This also renames ':completer' to ':async_completer' in constructed kernel, so it is compliant with what VM expects to see(and updates test expectations accordingly).
Further it fixes async stack navigation for sync-async that became default in dart vm since first version went for the review((uses `future` getter, rather than property).
It also makes `future` getter non-debuggable to allow stepping-out of async methods.
Make Handle zone-scoped. Clean up frame counter var name.
Bug: https://github.com/dart-lang/sdk/issues/29056
Change-Id: Ia71f3c851a6b313655b57dad28c296f5dd081eda
Reviewed-on: https://dart-review.googlesource.com/54640
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This ensures that the resulting Iterable will have the proper type
when run with strong mode semantics.
In Dart 1.0 semantics, the type argument to .map is ignored, so this
change should be safe.
Change-Id: I34924bc7e803b1520af7d174cfe80f5be6b7ac0f
Reviewed-on: https://dart-review.googlesource.com/55908
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is necessary because many call sites invoke toUserString without
first casting to one of the derived classes.
This should be safe since both derived classes (SourceLocation and
UnresolvedSourceLocation) contain a definition of toUserString.
Change-Id: I69eeda326883d87fc4e8cedd732881d250cae8cb
Reviewed-on: https://dart-review.googlesource.com/55909
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL fixes some cases where Observatory mistakenly tried to use a
C-style parameter declaration, e.g.
void foo(String);
The intent is to declare the parameter to have type `String`, but Dart
interprets the parameter as having *name* `String` and type `dynamic`.
In most cases the fix applies to abstract method declarations, whose
types aren't semantically relevant in Dart 1.0, so these parts of the
CL should be safe.
In one case it applies to a typedef, IsConnectedVMTargetDelegate. The
only use of this typedef is as the type of
TargetRepository._isConnectedVMTarget, whose value is always the
static function ObservatoryApplication.isConnectedVMTarget. The type
of ObservatoryApplication.isConnectedVMTarget matches the typedef
(according to Dart 1.0 rules) both before and after the change, so
this should be safe as well.
Change-Id: Ia67f5f14d5a012ccb8a44cbd88a8233f8c9ad171
Reviewed-on: https://dart-review.googlesource.com/55901
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
asiva