This is WIP - not quite ready for review.
Not all tests are passing yet. Most checker and inference tests are passing, but about a quarter are failing - need to look.
The non-runtime changes under lib along with test/testing.dart are the only real changes.
We seem to be losing some type info - lots of new casts - but I see at least one removed.
R=brianwilkerson@google.com, jmesserly@google.com, leafp@google.com
Review URL: https://codereview.chromium.org/1355893003 .
This:
- Ensures that a given AST is processed once per context, avoiding AST caching issues and redundant work
- Associates file errors with their library instead of the entry point - we now only generate these once across different entry points
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1376123004 .
This appears to cut out about 1/3 of the strong mode errors reported
in angular2. The actual cases removed that I looked at seem fine - e.g., we may inject an implicit cast, but it'll work fine at runtime.
Fixes#302R=leafp@google.com
Review URL: https://codereview.chromium.org/1310053005 .
this also implements multitest support, which fixes#280
Fixes some other preexisting bugs:
* MetaLets did not simplify themselves correctly in some nested cases
* Library prefixed identifiers did not work as lvalues in opassign
* dsetindex/dput/[]= methods did not return a value
* checker did not correctly handle invalid constructor field initializers
* cascades did not correctly work with method invocations(?)
* postfix ++/-- did not correctly generate lvalues in some cases
The good news: because this reuses on our existing lvalue/metalet helpers, it managed to flush out a lot of bugs in other features that use them.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1316723003 .
we weren't running a bunch of tests on the bots :|
amazingly, none were broken yet
this also fixes karma.conf log level, and disables some spammy prints from one of the tests
R=vsm@google.com
Review URL: https://codereview.chromium.org/1257233008 .
Main goal here was to get rid of the enter/exit compilation unit tracking, to allow further Compiler/Server refactoring. We can get the Uri/LineInfo/contents off Source, which AnalysisError already has
SummaryReporter is now fairly generic.
TODOs for the future:
* figure out what to do about ErrorCodes, in particular dev_compiler prefix feels off.
* skip the intermediate StaticInfo types? They're really just builders now for AnalysisError.
* don't classify all existing messages as "AnalyzerError" ... just print them ...
* skip logger. For our command line program, stdout is part of its "API", IMO it shouldn't use logging for those messages. Consider Pub, which uses stdout/err for its messages, and uses logging for more detailed troubleshooting.
R=pquitslund@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/1230903002.
Right now it maps straight to ES6 generators. This should handle some basic cases, but there's more work to get all of the corners working. For example: it doesn't implement Iterable yet.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1207313002.
This changes the way we handle dynamic at runtime to be more correct and cleaner. We now simply emit dynamic as dynamic instead of as core.Object. There are now two ways to construct a function type: one can construct a fuzzy function type (the default), or a definite function type. The constructor for a fuzzy function type replaces all uses of dynamic with bottom. This function type is used for all type annotations. Definite function types do not replace dynamic with bottom. These only occur as the runtime type of actual functions, for which we really know the type. Because we now eagerly sort this out when we create the function type, the subtyping code doesn't need to deal with this.
This allows some additional subtyping: closures which actually are typed to take dynamic would previously not have been allowed to be cast to something with a concrete argument type. Now this is allowed (see the change in runtime_tests.js for an example of this).
This fixes#107.
BUG=
R=vsm@google.com
Review URL: https://codereview.chromium.org/1195523002
The dart runtime files are roughly split around functional boundaries. Comments at the top of each file describe the function of the library. I'm not sure that these are 100% right yet, but they're closer. We may want to iterate on the organization.
The main dart runtime file just re-exports various symbols from the sub-libraries. It has hard dependencies on the other runtime files, some of which have soft (lazy) dependencies on SDK files. The generated code now depends on dart and dartx as a imported libraries, rather than as top level symbols.
This CL also includes some new code to make type representations a bit better. This is mostly in the new types.js file, which makes all of the non-instance types (dynamic, bottom, void, function types) subtypes of a common representation type. Among other things, they now have the correct runtime type (core.Type). Some of the type code has been rationalized around this a bit, but there is more left to do here. The setSignature code in classes.js now also places the correct runtime type on nominal (instance) types. There are new tests in the runtime_tests.js file to test for this.
The static object method code that implements the Object methods has not yet been updated to dispatch on type representations. I will do that in a separate CL.
BUG=
R=jmesserly@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/1182653002
Vijay Menon