-
Notifications
You must be signed in to change notification settings - Fork 194
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
base: main
Are you sure you want to change the base?
Conversation
@@ -488,6 +488,11 @@ extension Driver { | |||
|
|||
commandLine.appendFlag(.pluginPath) | |||
commandLine.appendPath(pluginPathRoot.localPluginPath) | |||
|
|||
if isFrontendArgSupported(.wasmPluginServerPath) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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!
# Conflicts: # Sources/SwiftDriver/Jobs/FrontendJobHelpers.swift
try commandLine.appendAll(.pluginPath, .externalPluginPath, .loadPluginLibrary, .loadPlugin, from: &parsedOptions) | ||
try addLoadPluginExecutableArguments(commandLine: &commandLine) |
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
@DougGregor order should now be fixed, plus a test to verify that 🫡 |
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 existingswift-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?)