- DownCastExact : Cases where the static type of rhs is exact
List<int> l = [1, 2, 3];
- DownCastDynamic : Cases where the static type of the rhs is a subtype (in Dart) of the static type of lhs:
List l = ...;
List<int> l2 = l;
R=jacobr@google.com
Review URL: https://chromereviews.googleplex.com/141647013
This CL adds composite coercions which reify the choices made by the typechecker in allowing a closure wrapping as explicit casts and wrappers. The code generators should now be able to just walk the coercion generating the appropriate code. Thoughts or suggestions about the design of this very welcome.
The closure wrapping decision process has changed as well. Instead of simply checking reverse subtyping (which allowed some closure wrapping which would change the runtime type), we now essentially do a more extended subtype check which allows downcasts (and a few other conversions) on arguments, and attempts to wrap or downcast the body. This enables wrapping for a common pattern we have encountered in which an untyped (and hence dynamically typed) lambda is passed into a typed context. It also allows closure wrapping for some cases that we may (or may not) prefer to reject, such as allowing an int -> int to be coerced to an Object -> Object and vice versa.
In follow up CLs, I will add a reifier which translates coercions to ast nodes, and will add some flags to try out different closure wrapping strategies.
BUG=
R=vsm@google.com
Review URL: https://chromereviews.googleplex.com/132147015
This adds some checker tests for subtyping generics. One test checks that generics are invariant in various ways, another checks that raw type subtyping works, and the last test covers multiple raw type subtyping for multiple parameter generics.
For the last test, it's not clear that this is the behavior that we want, but it's what's currently implemented.
BUG=
R=vsm@google.com
Review URL: https://chromereviews.googleplex.com/130137014
We were getting some corner cases of function subtyping in the presence of named and optional parameters wrong. This CL fixes the function subtyping method, and adds a test for a range of cases.
BUG=
R=vsm@google.com
Review URL: https://chromereviews.googleplex.com/134847013
For now I ripped out the temp machinery. With the current writer there's no easy way to put the variable declaration in the right place. We can revive it when we have something, like the NestedPrinter from source_maps pkg. For now cascades are only generated when the target is a simple identifier. (That too is wrong in the case of getters, with multiple evaluations, but it's less wrong. At least we don't mess up the syntactic structure of the generated output.)
R=vsm@google.com
Review URL: https://chromereviews.googleplex.com/128587013
This CL adds support for marking tests as known failures using the following syntax:
/*expectation1::shouldbe::expectation2*/
where expectation is either "level:StaticInfo" as before, or "pass".
The meaning is that the test is currently exhibiting incorrect behavior expectation1, but should exhibit behavior expectation2.
The test will succeed so long as expectation1 is matched, but a summary of the number of "shouldbe" expectations is printed at the end of running the test script. Currently this is just implemented as grep, we can make this fancier eventually.
I'm not particularly attached to the syntax, feel free to suggest alternatives.
This CL also adds a bunch of fairly mechanical tests of subtyping, a number of which we are definitely failing, and some of which we may or may not be failing depending on where we wish to insert automatic fixup code.
BUG=
R=vsm@google.com
Review URL: https://chromereviews.googleplex.com/129027013
- bin/
devc.dart
- lib/
devc.dart
src/
info.dart # static info we compute, used by checker & backends
checker/ # implementation details for the checker
checker.dart # checking algorithm
rules.dart # type checking rules
resolver.dart # same as today, type resolution via analyzer
emitter/
...
- test/
checker/ # unit tests for the checker internals
codegen/ # left as is - maybe should rename to emitter?
samples/ # stand alone samples that we run in the end_to_end tests.
...
R=vsm@google.com
Review URL: https://chromereviews.googleplex.com/128957013
This isn't quite right yet - it's in between our current static rules
and what we've been discussing changing. Will fix up more tomorrow,
but wanted to put this out for initial feedback.
R=leafp@google.com
Review URL: https://chromereviews.googleplex.com/117167015
Vijay Menon