Allow kernel service request to provide source files(filename, content), which will be used to build up MemoryFileSystem instance. MemoryFileSystem instance will be used instead of PhysicalFileSystem instance.
Immediate need for this is to support VM unit testing, where small Dart scripts that have to be parsed are hardcoded in the unit tests.
BUG=https://github.com/dart-lang/sdk/issues/28264R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2880453005 .
In the long term, this is intended to be used to communicate the
results of type inference from the front_end to analyzer. In the
short term, it can be used to debug type inference (by uncommenting
the print statements in type_inference_listener.dart).
R=scheglov@google.com, sigmund@google.com
Review-Url: https://codereview.chromium.org/2878733006 .
This allows for example to add SDK into a Program, then load the
"incomplete" Program A that has only the library A, and name sequences
that references SDK classes. Because we look into the nameRoot which
aleady has SDK CanonicalName(s), we can find these names while filling
the link table and use references which point to the existing SDK
AST nodes. Then we can load another set of library cycles, etc.
At the end we have a set of self-consistent libraries that we can
feed into DillTarget/DillLoader and resolve anothersource target
against it.
This CL is based on https://codereview.chromium.org/2872903005/
which has not been reviewed yet.
R=kmillikin@google.com, paulberry@google.com, sigmund@google.com
BUG=
Review-Url: https://codereview.chromium.org/2874723002 .
This functionality was duplicated both in
TypeCheckingVisitor.handleFunctionCall and in the front end's
TypeInferrerImpl._getCalleeFunctionType. I kept the implementation
from TypeInferrerImpl._getCalleeFunctionType since it does a binary
search, so it should theoretically be faster.
R=kmillikin@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2876533004 .
We need to compute the interface target in order to do the inference
anyway, so this is a reasonable time to store it.
Also annotate the inference tests with interface targets so that we
can verify that the interface targets computed by analyzer match those
computed by Fasta. Note that this causes a few strong mode tests to
fail that were previously passing, due to the fact that type inference
in Fasta is incomplete.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2874033003 .
This was broken for three reasons:
- We weren't recording the fact that the type parameters were
explicitly provided, so the inference code path to handle this case
wasn't being exercised.
- The inference code path to handle this case was accidentally
referring to the `inferredTypes` variable, which is `null` in this
case.
- We were not checking for the case where the user provided the wrong
number of type parameters.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2874053002 .
Several minor changes that shouldn't affect functionality:
- inferGenericFunctionOrType no longer returns the inferred type;
instead, it fills an "inferredTypes" array with the inferred type
arguments.
- Downwards inference is signaled to inferGenericFunctionOrType by
passing `null` for `formalTypes` and `actualTypes`.
- inferTypeFromConstraints no longer falls back on
instantiateToBounds. This never could have had any effect anyway
because it was only invoked for upwards inference, and in that case,
all type arguments are already known.
- Inferred type arguments are now passed back to
KernelConstructorInvocation as a list rather than forcing it to
extract them from the inferred class type. If the inferred class
type doesn't need to be computed, it isn't.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2869003002 .
* move isPseudo getter out of Token into TokenType
* move special case charCount logic out of fasta.Token into fasta.ErrorToken
* move more accessors from fasta.Token into analyzer.Token
* add @overrides to denote which methods have been declared in analyzer.Token
* make fasta LazySubstring and its subclasses private
* rename fasta.previousToken to previous to match analyzer.Token
* flatten fasta.Token.preceedingCommentTokens into preceedingComments
* normalize fasta.Token.next and analyzer.Token.next
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2872433005 .
Three problems are fixed:
- I forgot to pass the `downwards` flag when doing downwards inference.
- I forgot to initialize the `formalTypes` and `actualTypes` arrays.
- I wasn't tracking whether constructor type arguments were implicit
or explicit, so constructor type inference wasn't actually
happening.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2864853002 .
This CL swaps the behavior of greatest and least closure in
solveTypeConstraint. It also changes greatestClosure(?) to `dynamic`
rather than `Object`.
These changes bring front end type inference more closely into line
with analyzer type inference.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2872763002 .
Breaking change to be landed after all existing callsites
have been converted to use the new API.
This is part 2 of https://codereview.chromium.org/2842643004/
* make Keyword extend TokenType
* make TokenType.AS be the same object as Keyword.AS
* make TokenType.IS be the same object as Keyword.IS
* remove TokenType.KEYWORD
* remove unnecessary Keyword.info method
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2848493003 .
Paul Berry