Skip to content

[SR-1639] Fix linker errors for sourcekitd when in-process #2769

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

Conversation

modocache
Copy link
Contributor

@modocache modocache commented May 29, 2016

What's in this pull request?

Several SourceKit symbols are declared in sourcekitd/sourcekitd.h and sourcekitd/Internal.h, but are only implemented for OS X, in tools/SourceKit/tools/sourcekitd/lib/API/sourcekitdAPI-XPC.cpp. These need implementations that are only included in builds of SourceKit that use an in-process communication model (in other words, not XPC).

Add stub implementations of the undefined symbols for in-process builds. This reduces the number of linker errors, getting us closer to at least compiling SourceKit on Linux. Of course, these stub functions will not work at runtime, they'll just let us compile.

Resolved bug number: (SR-1639)


Before merging this pull request to apple/swift repository:

  • Test pull request on Swift continuous integration.

Triggering Swift CI

The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:

Smoke Testing

Platform Comment
All supported platforms @swift-ci Please smoke test
All supported platforms @swift-ci Please smoke test and merge
OS X platform @swift-ci Please smoke test OS X platform
Linux platform @swift-ci Please smoke test Linux platform

Validation Testing

Platform Comment
All supported platforms @swift-ci Please test
All supported platforms @swift-ci Please test and merge
OS X platform @swift-ci Please test OS X platform
OS X platform @swift-ci Please benchmark
Linux platform @swift-ci Please test Linux platform

Lint Testing

Language Comment
Python @swift-ci Please Python lint

Note: Only members of the Apple organization can trigger swift-ci.

Several SourceKit symbols are declared in `sourcekitd/sourcekitd.h` and
`sourcekitd/Internal.h`, but are only implemented for OS X, in
`tools/SourceKit/tools/sourcekitd/lib/API/sourcekitdAPI-XPC.cpp`.
These need implementations that are only included in builds of SourceKit that use an
in-process communication model (in other words, not XPC).

Add stub implementations of the undefined symbols for in-process builds. This
reduces the number of linker errors, getting us closer to at least *compiling*
SourceKit on Linux. Of course, these stub functions will not work at runtime,
they'll just let us compile.
@modocache modocache force-pushed the sr-1639-sourcekitd-in-process-definitions branch from b5b844e to 35f2dee Compare May 29, 2016 16:45
@modocache modocache changed the title [SR-1639] Fix linker errors for sourcekitd.h when in-process [SR-1639] Fix linker errors for sourcekitd when in-process May 29, 2016
set(LLVM_OPTIONAL_SOURCES ${sourcekitdAPI_Darwin_sources})
if(APPLE)
list(APPEND sourcekitdAPI_sources ${sourcekitdAPI_Darwin_sources})
set(sourcekitdAPI_InProc_sources sourcekitdAPI-InProc.cpp)
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 it is important that the concept of "Darwin sources" be preserved here. When building on Mac, both the standard and in-proc versions of sourcekitd use XPC services to implement these APIs. In the case of in-proc library, xpc_object_t is effectively used as a flexible DTO to implement the SourceKit request object.

An alternative implementation will indeed be required though for Linux, perhaps using some sort of C++ variant type. I've just begun poking looking into what this could look like but haven't gotten very far.

@briancroom
Copy link
Contributor

This is now obsoleted by #3000

Thanks for having helped get the ball rolling with this work @modocache!

@briancroom briancroom closed this Jun 24, 2016
@modocache
Copy link
Contributor Author

My pleasure, thank you! 👍

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.

2 participants