FFI and Incremental compiler doesn't work together

[jensjoha]

Because the FFI transformation changes the interface, and the way the CFE works, using FFI together with the incremental compiler doesn't work, and crashes.

This is an overview of what happens (example):

• We have 2 files, main.dart and lib.dart:
  main.dart:

import 'lib.dart';

main() {
    Coordinate coordinate = new Coordinate.allocate(42.0, 42.0, null);
    print(coordinate.x);
    print(coordinate.y);
    print(coordinate.next);
}

lib.dart

import 'dart:ffi';

class Coordinate extends Struct {
    @Double()
    double x;

    @Double()
    double y;

    Pointer<Coordinate> next;

    factory Coordinate.allocate(double x, double y, Pointer<Coordinate> next) {
    return null;
    }
}

• We first compile and everything is basically fine. The fields in lib.dart has been replaced though, and internally the CFE builder representing it / that initially build it, now has an inconsistent view of the world.
• We update main.dart and thus recompile it. Nothing imports main.dart so only main.dart needs to be rebuild. When doing that, type inference looks at "x", finds (via the builder in CFE) the now-removed field, tries to get the class it's in (via the field itself, namely the parent pointer), gets a null value and crashes when it tries to use it.

Even if it hadn't crashed, it would have pointed to something wrong (the basically non-existing field).

I will create a test and point to and from this issue.

[jensjoha]

https://dart-review.googlesource.com/c/sdk/+/128731/

[jensjoha]

FYI @dcharkes @sjindel-google @johnniwinther

[dcharkes]

Is the expression evaluation in the debugger affected by this as well?

[jensjoha]

Not that I'm aware --- and it works way differently anyway: The expression evaluation doesn't remove anything (which is one of the main problems with the ffi transformation) --- instead it creates a fake library with (possibly) a fake class and a procedure.

[dcharkes]

If it compiles the expression in isolation, and runs the VM transformations, that will not work properly. Because the two collections definition replacements would be empty. Those are used for replacing the references to the struct fields. Exactly the same issue as with hot reload.

[jensjoha]

I think I understand the previous question better now: You mean after doing a compilation with FFI involved, then doing an expression evaluation that use the (now non-existing) fields.
(I read your question as more general 'is expression calculation broken')

Yeah --- once the incremental compiler has come in a bad state (because of the ffi transformation) all subsequent compilations can be effected. This also includes expression evaluation.

[dcharkes]

Yes indeed, that is what I meant.

I just wanted to make sure a workaround (and a proper fix later) can also fix the expression evaluator in the debugger. (cc @mkustermann)

[jensjoha]

This should have been fixed with d21c4e4.
@dcharkes if you can verify that would be great.