Kernel mode should retain the existing support we have for Dart API

[a-siva]

Known issues that cause some Dart API functions to not work:

1. imports_field and exports_field in a library object are not initialized correctly

When using the --dfe option I noted that the library objects created in the VM heap do not seem to have the 'imports_' and 'exports_' fields initialized with the various imported/exported library objects. Is this intentional? How does lookup work if these entries are not populated?

For the test listed below, I stop in the debugger after Dart_LoadKernel is called and look at the library object returned and it shows the following:

imports_ field is initialized to an Array object of length 4, with the null object in each element of the array

exports_ field is initialized to the empty_array object.

A lot of functions like Library::LookupObjectAllowPrivate , Library::LookupReExport etc depend on these fields being set.

e.g
file junk.dart contains
import 'junk1.dart';

main() {
imported_main();
exported_main();
}

file junk1.dart contains
library junk1;

export 'junk2.dart';

imported_main() {
print("Import is working");
}

file junk2.dart contains
library junk2;

exported_main() {
print("Export is working");
}

2. Investigate other API calls that do not work

[kmillikin]

Yes, that's intentional. At least, it's a consequence of an intentional design.

Kernel is fully resolved, so there is no lookup the way you are thinking of it. That lookup happens when Dart is compiled to Kernel, and Kernel code can directly point to the things it names.

Kernel libraries don't have imports or exports. If we require that Kernel libraries and Dart libraries correspond one to one, then we could represent imports and exports syntactically in Kernel but they would still have no semantic effect. This raises the question of how a transformation that generated libraries would decide on their imports and exports (I suppose if we don't care that they are coherent with the Kernel program, it doesn't matter). And a transformation that combined libraries could no longer represent the original Dart source imports and exports correctly.

At this point, I'd like to figure out what reflective capabilities of Dart source code we should support for the VM's public API. My inclination is that these capabilities should be supported by querying the front end directly (because it knows all about Dart code) and not represented syntactically in Kernel.

Do you think it's possible to come up with a doc that enumerates the reflective capabilities we need?

[sivachandra]

For the first round, I will tackle the dartk failures in dart_api_impl_test.cc and debugger_api_impl_test.cc.

[a-siva]

Most of the API works, will not close this issue until we make sure all the status file entries in tests related to this are verified.

[dgrove]

any updates on this, @a-siva ?

[a-siva]

We still have some status file entries that turn off API tests in Dart 2 mode, bkonyi is working through the list.

[a-siva]

@bkonyi is it safe to say that we now support all of the Dart API surface in Dart 2?

[bkonyi]

For the most part all of the tests for the Dart API are passing or marked as SkipByDesign (for features not supported in Dart 2). However, there's still a few tests which need updating but aren't high priority:

• DartAPI_TypeGetParameterized: DartAPI_TypeGetParameterized fails due to inability to lookup core types #33042
• DartAPI_New: Dart_New cannot allocate using redirecting factory constructors in abstract classes #33041
• DartAPI_LazyLoadDeoptimizes: Rewrite DartAPI_LazyLoadDeoptimizes for Dart 2 #33043

[dgrove]

@bkonyi - I see that #33043 is now targeted for Dart2.1 . Is the rest of this issue required for Dart2Stable?

[bkonyi]

Sorry for the delay. I had discussed with @a-siva about #33041 and I think the conclusion we came to was that while we would prefer this made it into Dart2Stable, it's not essential. That issue is blocked by #33495, so I think we should be good to go (unless @a-siva has a different opinion). I'll move this issue to Dart2.1 to keep tracking the unresolved issues.

[dgrove]

Still targeted for 2.1?

[a-siva]

We have covered the Dart API surface area in kernel mode and so this generic bug can be closed. We have individual bugs for some cases where there are bugs.