Before landing, two issues to resolve:
(1) We appear to allow sideways casts now without static error - e.g.,
List<Object> -> FutureOr<List<String>>
Is that intended? If so, it breaks an assumption that implicit casts
are from supertype to subtype.
(2) LUB and FutureOr
It appears that the LUB of, e.g., String and Future<String> is Object.
See fixes in tests to record casts back to FutureOr.
Fixes#29251R=leafp@google.com
Review-Url: https://codereview.chromium.org/2801683004 .
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 .
* finish making fasta tokens implement analyzer token API
* move a couple things from analyzer into front_end
* Scanner useFasta flag
* SyntheticKeywordToken
* SyntheticStringToken
* add a fastaSupportsGenericMethodComments flag to more easily find
all of the places in the code that need to be addressed
when this functionality is added or dropped
* initialize linestarts in scanner adapter
* cleanup analyzer hints
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2794653002 .
So, I'm removing this flag that didn't allow us to perform invocation
type inference and caused bogus STRONG_MODE_INVALID_CAST_NEW_EXPR errors.
This causes us to perform inference where we don't need it, and report
(only informational?) info:INFERRED_TYPE_ALLOCATION for these invocations.
At the same point, we report errors for these cases, which should be
fixed anyway, and then downward inference will not be performed anymore.
R=brianwilkerson@google.com, leafp@google.com
BUG=
Review-Url: https://codereview.chromium.org/2779003004 .
1. When a literal is typed, and is not a constant, we don't need its
elements for type inference. Moreover, in this case elements are
allowed to include nodes that are not immediately-evident expressions,
such as instance creations without all type arguments, closures with
block bodies, etc.
2. When a literal is a constant, so we still have to serialize all its
elements, it is possible that we will encounter something not allowed
for immediately-evident expressions, and fail. But that's OK, because
such expressions are also not allowed in constants, so we will have
a compile time error anyway, and IMHO it is OK to degrade a little
in presence of errors.
3. The same is true for method invocations and instance creations,
we need to serialize arguments only for constants, because top-level
inference never uses arguments to infer returned types.
R=brianwilkerson@google.com
BUG=
Review-Url: https://codereview.chromium.org/2779993002 .
Konstantin Shcheglov