Open ferrantejake opened 1 month ago
Summary: The Dart compiler crashed during compilation due to a type mismatch. The compiler encountered an "InvalidType" which is not a subtype of "InterfaceType" during a type cast operation.
Can you share a minimal repro here? It looks like a @staticInterop
class' factory function's return type is being treated as an InvalidType
.
InvalidType
usually come from other static errors in the input program, but where the compiler continues running past that point.
I was able to repro with an example like this:
import 'dart:js_interop';
class A {}
@staticInterop
class A {
external factory A();
}
main() => A();
This produced a lot of static errors first, then the crash:
dart compile js q.dart
q.dart:6:7:
Error: 'A' is already declared in this scope.
class A {
^
q.dart:3:7:
Info: Previous declaration of 'A'.
class A {}
^
q.dart:7:20:
Error: 'A' isn't a type.
external factory A();
^
q.dart:7:20:
Info: This isn't a type.
external factory A();
^
q.dart:10:11:
Error: Can't use 'A' because it is declared more than once.
main() => A();
^
q.dart:6:7:
Error: `@staticInterop` classes should also have the `@JS` annotation.
class A {
^
q.dart:7:20:
Error: Only JS interop members may be 'external'.
external factory A();
^
q.dart:
Internal Error: The compiler crashed when compiling this element.
The compiler is broken.
When compiling the above element, the compiler crashed. It is not
possible to tell if this is caused by a problem in your program or
not. Regardless, the compiler should not crash.
The Dart team would greatly appreciate if you would take a moment to
report this problem at http://dartbug.com/new.
Please include the following information:
* the name and version of your operating system,
* the Dart SDK build number (3.6.0-255.0.dev), and
* the entire message you see here (including the full stack trace
below as well as the source location above).
The compiler crashed: type 'InvalidType' is not a subtype of type 'InterfaceType' in type cast
#0 StaticInteropClassEraser.visitStaticInvocation (package:_js_interop_checks/src/transformations/static_interop_class_eraser.dart:221:49)
#1 StaticInvocation.accept (package:kernel/ast.dart:6604:44)
I haven't tried this in the flutter tool, but I wonder if the errors are less visible in that case?
I wonder if we can bail early on some of our transformations if we know compile-time errors have already been emitted?
I wonder if we can bail early on some of our transformations if we know compile-time errors have already been emitted?
We do something somewhat similar here, but we can expand this to all errors and for more transforms. The transform in question is done in the backend, but we can still query the DiagnosticReporter
. That being said, I'm sure we'll still hit a crash at some point in the compilation pipeline because we assume InvalidType
doesn't exist.
I'll see what I can do to replicate the issue with a minimal repo - this has taken a backseat on priority but I wanted to share in case that trace was useful.