This allows the parser tests to be rewritten in a way that will make
them easier to adapt to testing Fasta, because they no longer make
assumptions about data structures passed around inside the parser.
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2684703007 .
This suppresses the emission of NO_DEFAULT_BOUND errors, and makes the
default instantation for recursive bounds backwards (and possibly
forwards) compatible. Also adds a couple of currently failing tests
for cases that should be made erroneous regardless of whether we
choose to support malbounded type constructor applications.
BUG=
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2662973005 .
Analyzer summaries do not yet support generic function-typed
parameters. To avoid user confusion, generate an error if the user
tries to use a generic function-typed parameter.
The error can be worked around by using a typedef or changing generic
types to `dynamic`.
R=brianwilkerson@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2656303004 .
This relaxes the restriction on raw types in bounds slightly, to allow
parameterized types in bounds to be used without type arguments if
their bounds are empty.
This CL also fixes the error check for raw types in type bounds to
apply to typedefs as well.
BUG=
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2658303002 .
fix#28527, FutureOr<T> subtyping with type parameters
For subtyping: we've had a long standing issue in how inference reuses the <: operator code. Inference needs to make sure constraints are recorded on the type parameters we're inferring, but it also needs to correctly implement the future or union. This change addresses that & is a step towards the bigger inference change upcoming that tracks top/bottom constraints explicitly.
R=leafp@google.com
Review-Url: https://codereview.chromium.org/2655273008 .
This implements FutureOr<T> in strong mode, otherwise it's ignored (treated as `dynamic`.
Also fixes strong mode's inference subtype function incorrectly treating `void` as a malformed type. This had the consequence of allowing `void` to be inferred as a type argument.
R=leafp@google.com, paulberry@google.com
Review-Url: https://codereview.chromium.org/2647833002 .
We're moving in the direction of resynthesizing dart:core and dart:async
classes on demand, in the same context as all the other sources. We will
not have a special AnalysisContext for SDK which we can ask TypeProvider
from.
R=brianwilkerson@google.com
BUG=
Review-Url: https://codereview.chromium.org/2651743005 .
Shows a hint when `Function` is used:
- as a class name,
- in an extends clause,
- in an implements clause,
- in a with clause.
The `Function` may or may not point to the core's `Function`. All uses of `Function` in these contexts are deprecated.
R=brianwilkerson@google.com
Review-Url: https://codereview.chromium.org/2643073002 .
The test was incorrect because it did not declare that a static warning
was to be expected due to an unresolved reference to 'q'. The unresolved
reference has been removed as it has nothing to do with what it is
supposed to test.
The analyzer was incorrect in that a setter was reported to clash with
a constructor of the same name, but this failure was hidden by the
above issue. This has been fixed.
dartk inherited the issue (and its fix) from the analyzer, but some
additional error handling was needed in dartk to avoid crashing.
Closes https://github.com/dart-lang/sdk/issues/11576
BUG=
R=kmillikin@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2643693002 .
Paul Berry