Only *.strong.expect files are included.
The tests are marked as failing for compile/, kompile/ and outline/.
I could generate them, but I don't think that these results are
actually "expected", it'd more like the "status quo".
R=ahe@google.com, paulberry@google.com
BUG=
Review-Url: https://codereview.chromium.org/2846103002 .
This method doesn't really belong in AstFactory, because it's not used
by BodyBuilder; it's used by KernelFieldBuilder, which always builds
kernel objects. We only need to abstract the objects that are created
by BodyBuilder, since only BodyBuilder is going to have to be capable
of building analyzer ASTs.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2842273002 .
This is a necessary prerequisite for re-using BodyBuilder to make
analyzer ASTs, since analyzer ASTs use tokens rather than offsets to
keep track of file positions.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2841863002 .
from front_end/lib/src/fasta/analyzer/
to analyzer/lib/src/fasta/
analyzer_compile and compile_platform_dartk moved
from front_end/lib/src/fasta/analyzer/
to front_end/tool/_fasta/
front_end/src/fasta/testing/* continues to have some shared testing logic,
- logic to compute the patched sdk is moved up one level
- TestContext, Run, and suite.dart (which depend on analyzer) moved to pkg/front_end/test/fasta/testing/
- only a copy of TestContext is duplicated under pkg/kernel/test/closure/.
R=ahe@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2828583003 .
1. A --platform flag is added to dart to give a path to a Kernel
binary for the platform libraries (as produced by building the
runtime_kernel target).
2. This binary is used for bootstrapping. Since it contains libraries
other then the VM's bootstrap libraries, they are also loaded.
3. The frontend does not send any library with a dart: import URI
scheme. Note that it does not (yet) prune the canonical name
table, which will contain a lot of unnecessary names used for
internal linkages in the platform libraries.
4. There is a single dependency in the platform libraries on the
script: _getMainClosure in dart:_builtin. This is patched after
the script is loaded.
BUG=
R=ahe@google.com, kustermann@google.com, vegorov@google.com
Review-Url: https://codereview.chromium.org/2786083002 .
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 .
Due to the tight coupling between analyzer and front_end, they need to
be published atomically. The last published version of kernel is old
enough that it needs to be published too.
I've bumped the versions to the following, and changed the
dependencies so that this set of versions is mutually compatible:
- analyzer: 0.30.0-alpha.3
- front_end: 0.1.0-alpha.2
- kernel: 0.2.0
(Note that kernel's version didn't need bumping since the most
recently published version of it is 0.1.0)
R=asgerf@google.com
Review-Url: https://codereview.chromium.org/2828273003 .
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 .
Konstantin Shcheglov