Skip to content

Deserialize Swift macro implementation paths from Swift modules #6753

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

Merged
merged 1 commit into from
May 4, 2023

Conversation

adrian-prantl
Copy link

This patch parses the Swift compiler plugin paths from all Swift modules and rewrites them to use swift-plugin-server where approprate and adds them to the Swift compiler invocation.

rdar://107030837

See also swiftlang/swift#65370

};

// Discover, rewrite, and unique compiler plugin paths.
for (auto path : extended_validation_info.getPluginSearchPaths()) {
Copy link

Choose a reason for hiding this comment

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

Are we worried about reading invalid local paths in distributed swiftmodules? LLDB could read paths to local macros from a different machine/configuration, it could make LLDB load undesired macro plugins on different machines. Similar to the issue we have with the search paths pointing to /Applications/Xcode.app/.

If so, LLDB could apply those paths only for local non-distributed module using the isNonUserModule check, if a module is non-user it's likely from the SDK, so we could ignore those paths. Alternatively, if we expect macros to be in the SDK we could filter out search paths for distributed modules that point outside the SDK.

Copy link
Author

Choose a reason for hiding this comment

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

Is isNonUserModule encoded in the validation info somewhere? I couldn't find it on first glance.

Copy link

Choose a reason for hiding this comment

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

It is available on ModuleDecl and ModuleEntity only at this time, but it only checks the path of the module file iirc so it should be possible to bring it down in the module loading logic as needed.

Copy link
Author

Choose a reason for hiding this comment

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

We no longer have the original path to the .swiftmodule file when debugging from a .dSYM where all .swiftmodule files have been concatenated into the __swift_ast section of the symbol-rich binary.

This patch parses the Swift compiler plugin paths from all Swift
modules and rewrites them to use swift-plugin-server where approprate
and adds them to the Swift compiler invocation.

rdar://107030837
@adrian-prantl
Copy link
Author

@swift-ci test

@adrian-prantl adrian-prantl merged commit a4a75f9 into swiftlang:swift/release/5.9 May 4, 2023
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