Add strong mode type checking pass.

Add strong mode type checking pass.

This is a piece of the upcoming strong mode-based type propagation.
The new type propagator will build its inference graph based on the
subtyping constraints found during type checking.

This type checker is not intended to report type errors to end-users.
In its current form, it is quite redundant with the front end's type
checker, but this will not be the case once we augment kernel's type
system.

The internals of "dart:" libraries are not type checked -- they are
simply assumed to satisfy the type annotations on their interfaces.

BUG=
R=kmillikin@google.com

Committed: https://github.com/dart-lang/kernel/commit/3baff07ec4bc6216947477cba8cce3a355be68b7

[asgerf, 2016-10-31 14:33:11]

Description was changed from

==========
Add strong mode type checking pass.

This is a piece of the upcoming strong mode-based type propagation.
The new type propagator will build its inference graph based on the
subtyping constraints found during type checking.

This type checker is not intended to report type errors to end-users.
In its current form, it is quite redundant with the front end's type
checker, but this will not be the case once we augment kernel's type
system.

BUG=
==========

to

==========
Add strong mode type checking pass.

This is a piece of the upcoming strong mode-based type propagation.
The new type propagator will build its inference graph based on the
subtyping constraints found during type checking.

This type checker is not intended to report type errors to end-users.
In its current form, it is quite redundant with the front end's type
checker, but this will not be the case once we augment kernel's type
system.

The internals of "dart:" libraries are not type checked -- they are
simply assumed to satisfy the type annotations on their interfaces.

BUG=
==========

[asgerf, 2016-10-31 15:11:24]

asgerf@google.com changed reviewers:
+ kmillikin@google.com

[Kevin Millikin (Google), 2016-11-01 13:03:01]

LGTM.

https://codereview.chromium.org/2465893002/diff/20001/lib/type_algebra.dart
File lib/type_algebra.dart (right):

https://codereview.chromium.org/2465893002/diff/20001/lib/type_algebra.dart#n...
lib/type_algebra.dart:176: /// Substitutes the type parameters on the class of
[type] with the
The comment is wrong here.

https://codereview.chromium.org/2465893002/diff/20001/lib/type_algebra.dart#n...
lib/type_algebra.dart:183: static Substitution combine(Substitution first,
Substitution second) {
It subtle that the implementation prefers first.  Maybe it needs a comment.

https://codereview.chromium.org/2465893002/diff/20001/lib/type_checker.dart
File lib/type_checker.dart (right):

https://codereview.chromium.org/2465893002/diff/20001/lib/type_checker.dart#n...
lib/type_checker.dart:156: node.function.positionalParameters
This checks the optional parameters twice, both here and in handleFunctionNode. 
Can't they just be checked by the call to handleFunctionNode after the
initializers are checked?

https://codereview.chromium.org/2465893002/diff/20001/lib/type_checker.dart#n...
lib/type_checker.dart:750: fail(node, 'Return from void method');
Return a value from void method.

[asgerf, 2016-11-01 13:59:36]

Thanks for the review!

https://codereview.chromium.org/2465893002/diff/20001/lib/type_algebra.dart
File lib/type_algebra.dart (right):

https://codereview.chromium.org/2465893002/diff/20001/lib/type_algebra.dart#n...
lib/type_algebra.dart:176: /// Substitutes the type parameters on the class of
[type] with the
On 2016/11/01 13:03:01, Kevin Millikin (Google) wrote:
> The comment is wrong here.

Thanks. Fixed it.

https://codereview.chromium.org/2465893002/diff/20001/lib/type_algebra.dart#n...
lib/type_algebra.dart:183: static Substitution combine(Substitution first,
Substitution second) {
On 2016/11/01 13:03:01, Kevin Millikin (Google) wrote:
> It subtle that the implementation prefers first.  Maybe it needs a comment.

Added some documentation.

https://codereview.chromium.org/2465893002/diff/20001/lib/type_checker.dart
File lib/type_checker.dart (right):

https://codereview.chromium.org/2465893002/diff/20001/lib/type_checker.dart#n...
lib/type_checker.dart:156: node.function.positionalParameters
On 2016/11/01 13:03:01, Kevin Millikin (Google) wrote:
> This checks the optional parameters twice, both here and in
handleFunctionNode. 
> Can't they just be checked by the call to handleFunctionNode after the
> initializers are checked?

You are right, this was not supposed to be here.

https://codereview.chromium.org/2465893002/diff/20001/lib/type_checker.dart#n...
lib/type_checker.dart:750: fail(node, 'Return from void method');
On 2016/11/01 13:03:01, Kevin Millikin (Google) wrote:
> Return a value from void method.

Done.

[asgerf, 2016-11-01 14:29:08]

PTAL at patch 4+5 (delta 5->3). I added some testing.

https://codereview.chromium.org/2465893002/diff/80001/testcases/strong-mode/D...
File testcases/strong-mode/DeltaBlue.baseline.txt (right):

https://codereview.chromium.org/2465893002/diff/80001/testcases/strong-mode/D...
testcases/strong-mode/DeltaBlue.baseline.txt:4: // dynamic is not a subtype of
dart.core::int (DeltaBlue.dart:139:15)
These are due to implicit casts not being inserted.

[Kevin Millikin (Google), 2016-11-01 14:39:03]

Tests LGTM.

[asgerf, 2016-11-01 14:43:35]

Description was changed from

==========
Add strong mode type checking pass.

This is a piece of the upcoming strong mode-based type propagation.
The new type propagator will build its inference graph based on the
subtyping constraints found during type checking.

This type checker is not intended to report type errors to end-users.
In its current form, it is quite redundant with the front end's type
checker, but this will not be the case once we augment kernel's type
system.

The internals of "dart:" libraries are not type checked -- they are
simply assumed to satisfy the type annotations on their interfaces.

BUG=
==========

to

==========
Add strong mode type checking pass.

This is a piece of the upcoming strong mode-based type propagation.
The new type propagator will build its inference graph based on the
subtyping constraints found during type checking.

This type checker is not intended to report type errors to end-users.
In its current form, it is quite redundant with the front end's type
checker, but this will not be the case once we augment kernel's type
system.

The internals of "dart:" libraries are not type checked -- they are
simply assumed to satisfy the type annotations on their interfaces.

BUG=
R=kmillikin@google.com

Committed:
https://github.com/dart-lang/kernel/commit/3baff07ec4bc6216947477cba8cce3a355...
==========

[asgerf, 2016-11-01 14:43:37]

Committed patchset #6 (id:100001) manually as
3baff07ec4bc6216947477cba8cce3a355be68b7 (presubmit successful).