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 should make the Link implementation work in strong mode.
We may find situations where Link<Null> leaks out, but I believe those should
be fixed by passing explicitly typed tail arguments.
Change-Id: I4c48769569f22e987ace586f5ec9264d75b49982
Reviewed-on: https://dart-review.googlesource.com/56663
Commit-Queue: Peter von der Ahé <ahe@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Known files are only used for seaching top-level declarations.
But we already get something for user from it - we can give Quick Fix
for imports, even if the package to import is not used yet in the project.
R=brianwilkerson@google.com
Change-Id: Iaa6d7ad515325b1bad3e37e7c066c42df056c85c
Reviewed-on: https://dart-review.googlesource.com/56623
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
In 4cf51e6c1a, a new argument was added
to the ContextRoot constructor, changing its signature in a breaking
way.
In theory this should not have broken other packages, because
ContextRoot is declared inside analyzer/lib/src. But it turns out
that two packages are known to import from analyzer/lib/src and
construct ContextRoot: angular_analyzer_plugin and
built_value_generator. To avoid breaking these packages, we need to
add the new constructor parameter as an optional (named) parameter.
Some time after after angular_analyzer_plugin and
built_value_generator have been updated, I'll send a later CL to mark
the named parameter as @required.
Change-Id: I5be063dd47a3dfefba08cb444687b91bf2ba3625
Reviewed-on: https://dart-review.googlesource.com/56603
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This reverts commit ad4cfa0260.
Reason for revert: Assertion failures on DBC
Original change's description:
> [mirrors] Add IsolateMirror.loadUri.
>
> This allows a programmer to dynamically load code into an isolate. The closest existing API is Isolate.spawnUri, but communication with the dynamically loaded code in that case is limited to asynchronous message passing of JSON-like objects.
>
> Change-Id: Icb23e9dacfb0035622c119f11d4e0f892ba2ccd1
> Reviewed-on: https://dart-review.googlesource.com/45363
> Reviewed-by: Zach Anderson <zra@google.com>
TBR=rmacnak@google.com,zra@google.com,asiva@google.com,kmillikin@google.com
Change-Id: I80669188b9f40b3b527e8e268ade0d0d514a8753
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/56640
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
It seems like the "missing" analysis error is a strong mode error, so I
don't think the error should even appear without strong mode turned on?
In any case, a "missing" error for non strong users is not something I
would expect to be blocking. Better to fix the build
Change-Id: I5f56b5847b655b501e8146200ab4b84fddbf21cc
Reviewed-on: https://dart-review.googlesource.com/56600
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This allows a programmer to dynamically load code into an isolate. The closest existing API is Isolate.spawnUri, but communication with the dynamically loaded code in that case is limited to asynchronous message passing of JSON-like objects.
Change-Id: Icb23e9dacfb0035622c119f11d4e0f892ba2ccd1
Reviewed-on: https://dart-review.googlesource.com/45363
Reviewed-by: Zach Anderson <zra@google.com>
This change adds tracking of number of invocations with the same
selector but different arguments. If this number reaches certain limit,
all subsequent invocations with such selector are approximated.
On Flutter gallery, 1 selector is approximated:
dart.core::Object::==
On Analyzer, 2 selectors are approximated:
analyzer.dart.ast.ast::AstNode::visitChildren
dart.core::List::[]=
Flutter gallery Total(CodeSize): +11 K.
Fixes https://github.com/dart-lang/sdk/issues/33199
Change-Id: I3598555194262a4f08fe1bc207d10880a25eb432
Reviewed-on: https://dart-review.googlesource.com/56420
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The transformation worked as if there was never an await "to the
right" of the body of a let expression (i.e., an expression evaluated
after the let expression's body but before the value of the let
expression's body is used). This is obviously not right.
Fixes https://github.com/dart-lang/sdk/issues/33206
Change-Id: Idc175dc8c65f3d520de8b65f2285164d361ff38e
Reviewed-on: https://dart-review.googlesource.com/56492
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Summary:
When evaluating constants for direct inspection (and not for injection into the
FG), we store many intermediate values in ZoneHandles. This leaks memory, since
the only need for ZoneHandles is preserving constants which are referenced by
the FG.
Test Plan:
Existing coverage is sufficient since no functionality is changed.
Change-Id: I33951eab762a4ad626f07ebf11118247c5a9ad3e
Reviewed-on: https://dart-review.googlesource.com/56345
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
# Summary
As part of commit 772c9bb5f, we changed the representation of partially
instantiated closures to facilitate partial instantiation of local functions.
The compile-time constant evaluator was not updated -- this revision implements
that update.
Fixes task 33211.
# Test Plan
Updated `partial_tearoff_instantiation_test.dart` to test the case which caused
incorrect behavior in task 33211.
Change-Id: I7bbd4fb83a5aea86ffc85c1d9952f1202f098d6b
Reviewed-on: https://dart-review.googlesource.com/56346
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Samir Jindel <sjindel@google.com>
Paul Berry