This is based on https://dart-review.googlesource.com/c/sdk/+/20481/10,
which required a rollback due to numerous secondary revealed issues.
Rather than deserializing function types with the proper scope, and
breaking inherited function type params, ie, `m(x)` where `x`
implicitly gets the type of `x` from `super.m(... x)`, deserialize
generic types incorrectly so that `const x = <Function<T>(T)>[]` fails
but `m(x)` works.
I have work towards fixing this issue, but it is incomplete (#31804),
and had to be rolled back and the fix is only getting more tangled:
https://dart-review.googlesource.com/c/sdk/+/33582.
For now, this will allow people to use Function types *without* type
parameters with no issues, and introduce no secondary issues, and
hopefully be a more straightforward change in and of itself.
-- From Rolled Back CL --
Remove field formal parameter test from other branch
Test genericFunctionType summarization deeper: params, return.
Didn't see a standard way of testing 'void' in the test so far, so I
followed some other tests and used isNotNull, which could be improved.
Fix type arguments vs parameters.
Fix#30858, generic function types not serializable when const.
Previously declaring for instance const lists (or even final lists) of
generic function types ie `final x = <void Function()>[]` would throw
errors during summarization.
The type parameters don't seem correctly stored yet, but that is an
edge case. Left a TODO, for now this should go in to prevent the
analyzer crash.
One thing I changed as well is that `serializeType` assumed it was
getting a type name, and `serializeTypeName` accepted types but threw
when it didn't get a type name. I flipped the names so that
`serializeTypeName` accepts a type name and `serializeType` accepts a
type in general and decides whether its a type name or a generic
function type to proceed with specialization.
Bug:
Change-Id: I98f5a362c9b2e8b3a7e87532ff4645b5963277ab
Reviewed-on: https://dart-review.googlesource.com/33660
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
new errors since the parameter type inference logic was changed:
analyzing pkg/analyzer...
error • Inconsistent declarations of 'getAncestor' are inherited from
<E>(dynamic) → E, <E extends Element>((Element) → bool) → E at
pkg/analyzer/lib/src/fasta/mock_element.dart:174:16 •
inconsistent_method_inheritance
error • Inconsistent declarations of 'getAncestor' are inherited from
<E>(dynamic) → E, <E extends Element>((Element) → bool) → E at
pkg/analyzer/lib/src/fasta/mock_element.dart:262:16 •
inconsistent_method_inheritance
error • Inconsistent declarations of 'getAncestor' are inherited from
<E>(dynamic) → E, <E extends Element>((Element) → bool) → E at
pkg/analyzer/lib/src/fasta/mock_element.dart:315:16 •
inconsistent_method_inheritance
error • Inconsistent declarations of 'getAncestor' are inherited from
<E>(dynamic) → E, <E extends Element>((Element) → bool) → E at
pkg/analyzer/lib/src/fasta/mock_element.dart:467:16 •
inconsistent_method_inheritance
error • Inconsistent declarations of 'getAncestor' are inherited from
<E>(dynamic) → E, <E extends Element>((Element) → bool) → E at
pkg/analyzer/lib/src/fasta/mock_element.dart:488:16 •
inconsistent_method_inheritance
error • Inconsistent declarations of 'getAncestor' are inherited from
<E>(dynamic) → E, <E extends Element>((Element) → bool) → E at
pkg/analyzer/lib/src/fasta/mock_element.dart:501:16 •
inconsistent_method_inheritance
6 errors found.
Bug:
Change-Id: I48b98e287bd6496b0745a1fcb42f87450cbfba9c
Reviewed-on: https://dart-review.googlesource.com/33180
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Before we used a hack to request resolution information for a single
library as needed, and requested kernels separately. This was hugely
inefficient (but faster to implement as a steel thread). We had then
recompile large library cycles many times, and take just one library.
Before: 480 seconds to compile analyzer (ouch!).
Now: 16 seconds (30 times faster).
Without --previewDart2: 14 seconds.
I will check why it is still slower later.
R=brianwilkerson@google.com, paulberry@google.com
Bug:
Change-Id: Ic3d47684daa74c53f0336523e17b656f26328acf
Reviewed-on: https://dart-review.googlesource.com/33144
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This reverts commit 60ee2c0dcd.
Reason for revert: Requires https://dart-review.googlesource.com/c/sdk/+/33180 which can land first.
Original change's description:
> Fix#30858, generic function types not serializable when const.
>
> Previously declaring for instance const lists (or even final lists) of
> generic function types ie `final x = <void Function()>[]` would throw
> errors during summarization.
>
> The type parameters don't seem correctly stored yet, but that is an
> edge case. Left a TODO, for now this should go in to prevent the
> analyzer crash.
>
> One thing I changed as well is that `serializeType` assumed it was
> getting a type name, and `serializeTypeName` accepted types but threw
> when it didn't get a type name. I flipped the names so that
> `serializeTypeName` accepts a type name and `serializeType` accepts a
> type in general and decides whether its a type name or a generic
> function type to proceed with specialization.
>
> Bug: 30858
> Change-Id: Id128f8625cbf03bb94d05ff0efdbac3b158e637e
> Reviewed-on: https://dart-review.googlesource.com/20481
> Reviewed-by: Paul Berry <paulberry@google.com>
> Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
TBR=paulberry@google.com,scheglov@google.com,mfairhurst@google.com
Change-Id: I6fae28335f7815b1e8c43597fb9451519a13335e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 30858
Reviewed-on: https://dart-review.googlesource.com/33200
Reviewed-by: Mike Fairhurst <mfairhurst@google.com>
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Previously declaring for instance const lists (or even final lists) of
generic function types ie `final x = <void Function()>[]` would throw
errors during summarization.
The type parameters don't seem correctly stored yet, but that is an
edge case. Left a TODO, for now this should go in to prevent the
analyzer crash.
One thing I changed as well is that `serializeType` assumed it was
getting a type name, and `serializeTypeName` accepted types but threw
when it didn't get a type name. I flipped the names so that
`serializeTypeName` accepts a type name and `serializeType` accepts a
type in general and decides whether its a type name or a generic
function type to proceed with specialization.
Bug: 30858
Change-Id: Id128f8625cbf03bb94d05ff0efdbac3b158e637e
Reviewed-on: https://dart-review.googlesource.com/20481
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reland of https://dart-review.googlesource.com/c/sdk/+/29160
Adds a 'severity' field to diagnostic messages and replaces all
addWarning and addNit functions by a generic addProblem, which uses
the intrinsic severity of the message. Eventually, errors should
also be reported this way.
A special severity value maps into either warning or error for Dart 1
and Dart 2, respectively. Most Dart 1 warnings are in this category.
Fixes some 320 failures of DDK test expecting a compile-time error.
These were previously masked by a workaround in the DDC error handler
which has now been removed.
Closes https://github.com/dart-lang/sdk/issues/31286
Change-Id: Id3b3b7f1fc6a101639fc908c90f3ec7d304a7b4b
Reviewed-on: https://dart-review.googlesource.com/32580
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Looks like the best place to put this is in the type builder, which has
special logic for foreaches. Previously, that special logic did not
include a need to visit the type, but with [GenericFunctionType]s, its
now necessary.
New test added; fails with kernel.
Bug: 31708
Change-Id: I6536be816a84458cf81d9037289ce6415ed13985
Reviewed-on: https://dart-review.googlesource.com/32447
Commit-Queue: Mike Fairhurst <mfairhurst@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Adds a 'severity' field to diagnostic messages and replaces all
addWarning and addNit functions by a generic addProblem, which uses
the intrinsic severity of the message. Eventually, errors should
also be reported this way.
A special severity value maps into either warning or error for Dart 1
and Dart 2, respectively. Most Dart 1 warnings are in this category.
Fixes some 320 failures of DDK test expecting a compile-time error.
These were previously masked by a workaround in the DDC error handler
which has now been removed.
Closes https://github.com/dart-lang/sdk/issues/31286
Change-Id: I6acea31b8cba7dec8b318e081d28f4eb4ebbf75c
Reviewed-on: https://dart-review.googlesource.com/29160
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Before: Kernel static errors were represented by throwing a distinguished
error or else by calling a distinguished library const constructor.
Now: Kernel static errors are represented by InvalidExpression. To support
error reporting, InvalidExpression has an optional message and a file
offset. A back end can choose to signal these errors at any time; for
example, when deserializing the binary, or when compiling the procedure
containing the static error, or when the erroneous expression is evaluated
at run time.
InvalidStatement is removed because it can be encoded as ExpressionStatement
of InvalidExpression.
Future work:
* supporting static errors where an expression cannot appear in the AST
* allowing InvalidExpression to contain an Expression for error recovery
* adding a top-level list of static errors and warnings to the binary
Bug: https://github.com/dart-lang/sdk/issues/29840
Change-Id: Ifdfe9a76cee6cefed28061bf245be70531d2f413
Reviewed-on: https://dart-review.googlesource.com/31320
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Konstantin Shcheglov