This CL makes four classes:
- TypeInferrer, which is the API for type inference within a method
body or field initializer, used by BodyBuilder.
- TypeInferrerImpl, which is the generic implementation of
TypeInferrer.
- TypeInferenceEngine, which is the API for top level type inference
and for creating TypeInferrers.
- TypeInferenceEngineImpl, which is the generic implementation of
TypeInferenceEngine.
R=karlklose@google.com
Review-Url: https://codereview.chromium.org/2830313002 .
This CL hooks up enough infrastructure for doing simple top level type
inference of variables whose initializer is an int.
Additional type inference rules will be added in follow-up CLs.
R=karlklose@google.com
Review-Url: https://codereview.chromium.org/2828253003 .
This is necessary because some of the TypeInferrer's roles (e.g. type
promotion and determination of the types of constants) are still
needed in non-strong mode.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2829683008 .
This CL introduces Fasta's first type inference rule, and hooks it up
to all the necessary testing infrastructure. The rule is that a local
variable whose initializer is an integer literal should have an
inferred type of int.
Only variables occurring at top level within a method are inferred (we
don't yet recurse inside sub-blocks).
Additional type inference rules will be added in follow-up CLs.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2828693003 .
In a future CL I need to add an import to this file, and for reasons I
haven't been able to track down, doing so causes type inference
failures. This CL works around the problem by making the affected
types explicit.
Once the bug is fixed, I hope to be able to revert this.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2833563004 .
The framework will allow test source files to be annotated with
comments indicating where types are expected to be inferred, for
example:
var /*@type=dart.core::int*/ x = 1;
Other features of the testing framework:
- Normally only those expectations explicitly listed will be checked.
The special comment "/*@testedFeatures=inference*/" at the top of
the file turns on extra checking which will cause the test to fail
if any unexpected type inference occurs.
- Should be easy to extend to support other features, such as checking
that the proper errors and warnings are generated at the proper
locations.
- If the test is run with "-DupdateExpectations=true", the
expectations will be updated in place.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2824393002 .
Change the front_end's shadow class hierarchy so that instead of
containing implementation classes and mixin classes, it only contains
implementation classes. The mixins proved to be unnecessary.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2819423004 .
Retrying https://codereview.chromium.org/2803563003
* update analyzer.Keyword list to include all of the fasta keywords
* enhance the analyzer scanner keyword table to handle uppercase
keywords such as "Function"
* update analyzer's parser to process the new KeywordTokens
* fix analyzer error verification
* update translation of fasta <--> analyzer tokens
* update tests and cleanup analyzer warnings
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2799133003 .
* update analyzer.Keyword list to include all of the fasta keywords
* enhance the analyzer scanner keyword table to handle uppercase
keywords such as "Function"
* update analyzer's parser to process the new KeywordTokens
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2803563003 .
This was de-duped in 02573b3caa, however
there's a problem: In order to share type inference and error
detection logic between Fasta's AstBuilder and BodyBuilder classes,
Fasta's use of the accessors needs to be rewritten to make use of the
shadow hierarchy (see
pkg/front_end/lib/src/fasta/builder/shadow_ast.dart), which kernel
shouldn't have to depend on.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2794013003 .
Paul Berry