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

[Macros] Add support for wasm plugins #1582

Draft
wants to merge 17 commits into
base: main
Choose a base branch
from

Conversation

kabiroberai
Copy link
Contributor

This PR implements the driver portion of support for Wasm Macros in Swift. The frontend requires the driver's help to locate swift-wasm-plugin-server, which we obtain in a similar fashion to the existing swift-plugin-server.

Counterpart to swiftlang/swift#73031 — will mark this as a draft until that PR lands but would appreciate input on the approach here (is explicitly passing -wasm-plugin-server-path the right approach or should we do something different?)

@@ -488,6 +488,11 @@ extension Driver {

commandLine.appendFlag(.pluginPath)
commandLine.appendPath(pluginPathRoot.localPluginPath)

if isFrontendArgSupported(.wasmPluginServerPath) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think instead this chunk of code should live in WebAssemblyToolchain's implementation of toolchain.addPlatformSpecificCommonFrontendOptions so that other platforms' command-lines don't unnecessarily end up with this flag.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, wasm macros can be invoked by any toolchain and so this server can also be used by any toolchain — it's independent of the target triple.

That said we could still be smarter about this and only pass along the wasm-server iff the user has also passed in a wasm macro. I avoided this initially because I didn't want the Driver to have to parse plugin load options to determine if a wasm macro was being loaded, but if cluttering up the options is a concern then it might be worth it. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated with a hasWasmPlugins check, let me know if this looks better!

Sources/SwiftDriver/Jobs/FrontendJobHelpers.swift Outdated Show resolved Hide resolved
Comment on lines 313 to 314
try commandLine.appendAll(.pluginPath, .externalPluginPath, .loadPluginLibrary, .loadPlugin, from: &parsedOptions)
try addLoadPluginExecutableArguments(commandLine: &commandLine)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. This is going change the relative ordering of -load-plugin-executable arguments with respect to the other plugin-like arguments, which we generally try to avoid. I think we'll need to iterate through all of the options, selecting these ones and translating the -external-plugin-path ones on-the-fly. I do appreciate how this approach makes the SwiftPM changes more limited, though, so SwiftPM can "just" treat wasm plugins like any other external plugin executable.

Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like us to keep the plugin-related arguments in order, because we've had to craft the order very carefully and need to not perturb it.

@kabiroberai
Copy link
Contributor Author

@DougGregor order should now be fixed, plus a test to verify that 🫡

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants