BridgeJS: Use @JS types from other modules in the same package

[wfltaylor]

Support using @JS types from one internal module in @JS API in another.

This works by parsing the BridgeJS skeleton of each dependency, and using that to resolve types if we fail to find a match within the target. The skeleton of the dependency is passed to the tool using --dependency-skeleton <Module>=<path>. For this to work with the BridgeJS build plugin, the dependency must contain a BridgeJS config file to declare that it uses BridgeJS.

There is no attempt to match Swift’s type resolution exactly: most ambiguity requires the module to be explicitly specified. Local types will shadow external types matching Swift’s behaviour.

This doesn’t support module selectors, since I think this would require bumping the minimum SwiftSyntax version.

This doesn’t support using types from modules in other packages. Extending an @JS type defined in another module is also unsupported.

A required field is introduced into the skeleton format. As far as I am aware this shouldn’t be an issue, since there is no need for the skeleton format to be backwards compatible at this time. If there is in fact such need, it should be trivial to make this optional when decoding.

Addresses issue #720

[kateinoigakukun]

Thanks for working on this! I still haven't taken a closer look at the diff but a few questions:

1. Do we support AOT codegen cases? To codegen AOT, we need to require all dependency modules to AOT codegen as well to get skeletons. Can we produce a clear diagnostic when BridgeJS plugin is configured for a dependency module but not AOTed.
2. Did you see any particular blocker for supporting cross-package reference?

[wfltaylor]

Thanks for working on this! I still haven't taken a closer look at the diff but a few questions:

1. Do we support AOT codegen cases? To codegen AOT, we need to require all dependency modules to AOT codegen as well to get skeletons. Can we produce a clear diagnostic when BridgeJS plugin is configured for a dependency module but not AOTed.

Yep, this is supported. I’ve pushed a commit to emit a diagnostic when attempting to AOT codegen a target which depends on a BridgeJS enabled target which has not been AOT codegened. If you don’t explicitly specify the target, it will AOT codegen them all in the correct order.

2. Did you see any particular blocker for supporting cross-package reference?

I tried to keep the scope of this PR smaller so I didn’t look into it too much, but this should be possible as long as we can find the skeleton file. I’m not sure how build plugins work in package dependencies, but I believe the worst case would be requiring the dependency to use AOT codegen for this use case.

[wfltaylor]

Thanks for working on this! I still haven't taken a closer look at the diff but a few questions:

1. Do we support AOT codegen cases? To codegen AOT, we need to require all dependency modules to AOT codegen as well to get skeletons. Can we produce a clear diagnostic when BridgeJS plugin is configured for a dependency module but not AOTed.

Yep, this is supported. I’ve pushed a commit to emit a diagnostic when attempting to AOT codegen a target which depends on a BridgeJS enabled target which has not been AOT codegened. If you don’t explicitly specify the target, it will AOT codegen them all in the correct order.

2. Did you see any particular blocker for supporting cross-package reference?

I tried to keep the scope of this PR smaller so I didn’t look into it too much, but this should be possible as long as we can find the skeleton file. I’m not sure how build plugins work in package dependencies, but I believe the worst case would be requiring the dependency to use AOT codegen for this use case.

Or I guess we could just re-parse the source assuming we are able to locate that.

[krodak]

Hey William,

Really like how this came together. The ExternalModuleIndex is a clean abstraction, the disambiguation via module qualifiers follows Swift conventions naturally, and local-shadows-external is the right default. The dependency ordering in the command plugin and the build plugin skeleton discovery are well thought through.

Thanks for the detailed comment in BridgeJSTool.swift about the skeleton-to-Swift injective mapping invariant and the hash escape hatch if it ever breaks. That kind of forward-looking note saves a lot of head-scratching later.

Test coverage is solid across type categories, structural positions, multi-module scenarios, and error diagnostics. The AOT diagnostic from commit 2 and the resource-bundling fix in commit 3 are both good catches.

LGTM!

[kateinoigakukun]

Overall looks good to me!