Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cfe] Unhandled 'ReachabilityError' with record getter coercion #51404

Closed
eernstg opened this issue Feb 14, 2023 · 1 comment
Closed

[cfe] Unhandled 'ReachabilityError' with record getter coercion #51404

eernstg opened this issue Feb 14, 2023 · 1 comment
Labels
area-front-end Use area-front-end for front end / CFE / kernel format related issues. type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@eernstg
Copy link
Member

eernstg commented Feb 14, 2023

Consider the following program:

void main() {
  dynamic x = 3.14;
  var record = ('Hello', x);
  var (s, double d) = record; // OK at compile time.
  var (s2, String s3) = record; // OK at compile time.
}

This program is accepted by the analyzer (as expected). It is also accepted by the CFE, but both dart and dart compile js give rise to executions where an unhandled ReachabilityError occurs when the second pattern declaration is reached.

I'd expect these pattern declarations to be accepted at compile time, and also to be compiled to code where a coercion takes place during initialization of the variable d respectively s3: The matched value is obtained from record by invoking the getter $2, and the return type of that getter is dynamic, and hence there should be a dynamic type check when the initialization of each of those variables is just about to occur. So we'd expect the program to run the first pattern declaration successfully and then throw a TypeError when it reaches the dynamic type check for s3.

However, it looks like the generated code is faulty, and some inconsistency is detected at the point where that dynamic type check could have taken place. In any case, it is certainly not obvious why we would encounter a ReachabilityError rather than a TypeError.

With the CFE from commit bedcd57, we get the following response from an execution of dart respectively the JS code generated by dart compile js:

Unhandled exception:
ReachabilityError
#0      main (file:///usr/local/google/home/eernst/lang/dart/scratch/202302/n006.dart:7:3)
#1      _delayEntrypointInvocation.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:297:19)
#2      _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:192:26)
/usr/local/google/home/eernst/bin/dart-sdk/lib/_internal/js_runtime/lib/preambles/d8.js:263: ReachabilityError
          throw e;
          ^
ReachabilityError
    at Object.wrapException (out.js:310:17)
    at main (out.js:2251:17)
    at action (/usr/local/google/home/eernst/bin/dart-sdk/lib/_internal/js_runtime/lib/preambles/d8.js:275:31)
    at eventLoop (/usr/local/google/home/eernst/bin/dart-sdk/lib/_internal/js_runtime/lib/preambles/d8.js:258:9)
    at self.dartMainRunner (/usr/local/google/home/eernst/bin/dart-sdk/lib/_internal/js_runtime/lib/preambles/d8.js:276:5)
    at out.js:2804:7
    at out.js:2789:7
    at dartProgram (out.js:2800:5)
    at out.js:2808:3
@eernstg eernstg added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) area-front-end Use area-front-end for front end / CFE / kernel format related issues. labels Feb 14, 2023
@eernstg
Copy link
Member Author

eernstg commented Mar 26, 2023

Closing: The given example does not cause a ReachabilityError any more.

@eernstg eernstg closed this as completed Mar 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-front-end Use area-front-end for front end / CFE / kernel format related issues. type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

1 participant