Can't compile stream_channel tests with build_vm_compilers

[natebosch]

Maybe some problem with package cycles or something?

Repro steps:

• Clone stream_channel repo.
• Add build_runner, build_vm_compilers, and build_test dependencies.
• pub run build_runner build. See a stack trace.

Crash when compiling package:test_core/test_core.dart,
at character offset null:
Reference to root::package:stream_channel/stream_channel.dart is not bound to an AST node. A library was expected
#0      Reference.asLibrary (package:kernel/ast.dart:219:7)
#1      LibraryDependency.targetLibrary (package:kernel/ast.dart:527:57)
#2      SourceLoader.computeFullComponent (package:front_end/src/fasta/source/source_loader.dart:783:38)
...

[jakemac53]

I can repro this both with build_vm_compilers and with build_web_compilers with kernel enabled.

[corwinsheahan-wf]

@jakemac53 @natebosch Any update on this? We're seeing this same error in an internal package and have been unable to narrow down a specific cause of the issue. Any insights gleaned from this issue may help us solve ours!

[jakemac53]

No - looks like we failed to follow up here.

I am getting a different error now:

org-dartlang-app:///packages/test_api/backend.dart: Internal problem: Unhandled Null in finalizeExports.

[jakemac53]

cc @jensjoha would you be able to take a look here?

[jakemac53]

This is especially weird given that we do have integration tests that test basic vm tests, so they are succeeding at compiling the test_core package.

[natebosch]

I wonder if this has something to do with the fact that we're in a package cycle with package:test.

This repros with this file in that package:

import 'package:test/test.dart';

void main() {
}

[natebosch]

I also see that when we are trying to compile to kernel for test.vm.dill the string stream_channel doesn't show up anywhere in an --input-linked argument. I strongly suspect this has something to do with the root package being in a package cycle.

[jakemac53]

Interesting - definitely worth taking a look at.

[corwinsheahan-wf]

FWIW, our case also seems to be an artifact of having a package cycle. Removing the cycle obviates the issue.

[jensjoha]

The current reproducible bug (Internal problem: Unhandled Null in finalizeExports.) is caused by:

• We're asked to compile package:test/test.dart
• We're given lots of inputs, among them org-dartlang-app:///packages/test_api/src/util/iterable_set.vm.dillcontaining (exactly) the library package:test_api/src/util/iterable_set.dart; and org-dartlang-app:///packages/test_api/backend.vm.dill containing (exactly) package:test_api/backend.dart. These two inputs are the only ones containing anything from package:test_api.
• When we process the exports of package:test_api/backend.dart we throw on the first one (https://github.com/dart-lang/test/blob/045ccf54b2330306925c3e14de18f24b3a381e7c/pkgs/test_api/lib/backend.dart#L9) because the file is not included in any of the given input.

Granted, the error thrown could be better, but nevertheless we're simply given a bad input.

(The 4 files exported by backend.dart, btw, we were asked to compile into metadata.vm.dill --- a file that we're never given again.)

[jakemac53]

So it sounds like this has to do with exports specifically then? I can look at the code on our end and see if there is anything obvious missing there.

[jensjoha]

I don't know how build is structured --- on the front end side exports aren't really special - the dill-input generally has to be closed.

[jakemac53]

I did look into this a bit but wasn't able to immediately find anything, as far as I can tell we correctly treat all directives as dependencies.

I can pick this back up again next week. I do have one hunch that it could have to do with how sometimes we provide dependencies as a source file and sometimes as a dill file (and this happens more often in the case of package cycles).

[jakemac53]

build_vm_compilers is no longer supported