Make it possible to represent type schemas in the front end.

Make it possible to represent type schemas in the front end.

See https://github.com/dart-lang/sdk/pull/29371/files for more
information.

R=ahe@google.com

Committed: https://github.com/dart-lang/sdk/commit/378538508353890245fc6e1f886ee10b12be25be

[Paul Berry, 2017-04-23 12:38:37]

Description was changed from

==========
Make it possible to represent type schemas in the front end.

See https://github.com/dart-lang/sdk/pull/29371/files for more
information.
k
==========

to

==========
Make it possible to represent type schemas in the front end.

See https://github.com/dart-lang/sdk/pull/29371/files for more
information.
==========

[Paul Berry, 2017-04-23 12:56:15]

paulberry@google.com changed reviewers:
+ ahe@google.com, asgerf@google.com, jmesserly@google.com, kmillikin@google.com,
leafp@google.com

[Paul Berry, 2017-04-23 12:56:15]

Note: I also considered the possibility of putting the new `UnknownType` class
inside kernel.

On the upside, this would eliminate the need for typeSchemaToString,
TypeSchemaPrinter, or TypeSchemaVisitor (we could just merge the new
functionality into the existing printer/visitor logic), and it would avoid the
need for an “is” check in UnknownType.accept().

On the downside, it would blur the code ownership boundary, since in principle
UnknownType should only be known about by the type inference process, and never
appears in actual programs.

What do you all think?

[ahe, 2017-04-24 13:21:07]

lgtm

https://codereview.chromium.org/2839513002/diff/1/pkg/front_end/lib/src/fasta...
File pkg/front_end/lib/src/fasta/type_inference/type_schema.dart (right):

https://codereview.chromium.org/2839513002/diff/1/pkg/front_end/lib/src/fasta...
pkg/front_end/lib/src/fasta/type_inference/type_schema.dart:49: /// purely part
of the local inference process.
I suggest that you extend pkg/front_end/lib/src/fasta/kernel/verifier.dart to
check this.

https://codereview.chromium.org/2839513002/diff/1/pkg/front_end/lib/src/fasta...
pkg/front_end/lib/src/fasta/type_inference/type_schema.dart:53: bool operator
==(Object other) => other is UnknownType;
Perhaps you should add a note that this class can't have any fields.

https://codereview.chromium.org/2839513002/diff/1/pkg/front_end/lib/src/fasta...
pkg/front_end/lib/src/fasta/type_inference/type_schema.dart:60: return
v.defaultDartType(this);
Perhaps this should throw?

[Paul Berry, 2017-04-24 18:33:32]

https://codereview.chromium.org/2839513002/diff/1/pkg/front_end/lib/src/fasta...
File pkg/front_end/lib/src/fasta/type_inference/type_schema.dart (right):

https://codereview.chromium.org/2839513002/diff/1/pkg/front_end/lib/src/fasta...
pkg/front_end/lib/src/fasta/type_inference/type_schema.dart:49: /// purely part
of the local inference process.
On 2017/04/24 13:21:07, ahe wrote:
> I suggest that you extend pkg/front_end/lib/src/fasta/kernel/verifier.dart to
> check this.

Ooh, good idea.  I will do that in a follow-up CL.

https://codereview.chromium.org/2839513002/diff/1/pkg/front_end/lib/src/fasta...
pkg/front_end/lib/src/fasta/type_inference/type_schema.dart:53: bool operator
==(Object other) => other is UnknownType;
On 2017/04/24 13:21:07, ahe wrote:
> Perhaps you should add a note that this class can't have any fields.

Done.

https://codereview.chromium.org/2839513002/diff/1/pkg/front_end/lib/src/fasta...
pkg/front_end/lib/src/fasta/type_inference/type_schema.dart:60: return
v.defaultDartType(this);
On 2017/04/24 13:21:07, ahe wrote:
> Perhaps this should throw?

That's what I had at first but it had a poor interaction with the kernel's
implementation of DartType.toString(), which uses a visitor to recurse over the
type (rather than making recursive calls to toString()).  If this method throws,
then calling toString() on a legitimate type schema like List<?> will throw. 
That seemed bad since we use toString() for debugging so often.

Incidentally, this is one of the reasons it might be worth moving UnknownType
into kernel.

[Paul Berry, 2017-04-24 18:40:26]

Description was changed from

==========
Make it possible to represent type schemas in the front end.

See https://github.com/dart-lang/sdk/pull/29371/files for more
information.
==========

to

==========
Make it possible to represent type schemas in the front end.

See https://github.com/dart-lang/sdk/pull/29371/files for more
information.

R=ahe@google.com

Committed:
https://github.com/dart-lang/sdk/commit/378538508353890245fc6e1f886ee10b12be25be
==========

[Paul Berry, 2017-04-24 18:40:27]

Committed patchset #1 (id:1) manually as
378538508353890245fc6e1f886ee10b12be25be (presubmit successful).

[ahe, 2017-04-24 19:46:05]

https://codereview.chromium.org/2839513002/diff/1/pkg/front_end/lib/src/fasta...
File pkg/front_end/lib/src/fasta/type_inference/type_schema.dart (right):

https://codereview.chromium.org/2839513002/diff/1/pkg/front_end/lib/src/fasta...
pkg/front_end/lib/src/fasta/type_inference/type_schema.dart:60: return
v.defaultDartType(this);
On 2017/04/24 18:33:32, Paul Berry wrote:
> On 2017/04/24 13:21:07, ahe wrote:
> > Perhaps this should throw?
> 
> That's what I had at first but it had a poor interaction with the kernel's
> implementation of DartType.toString(), which uses a visitor to recurse over
the
> type (rather than making recursive calls to toString()).  If this method
throws,
> then calling toString() on a legitimate type schema like List<?> will throw. 
> That seemed bad since we use toString() for debugging so often.
> 
> Incidentally, this is one of the reasons it might be worth moving UnknownType
> into kernel.

Good point. Perhaps add a comment about this problem.