[SR-1613] Require blocks runtime when compiling SourceKit on Linux

[modocache]

Previous ID	SR-1613
Radar	None
Original Reporter	@modocache
Type	Sub-task
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Package Manager, XCTest
Labels	Sub-task
Assignee	@modocache
Priority	Medium

md5: a526276c1e36b2d3cc9732aad041c42b

Parent-Task:

• SR-710 Generate XCTestCaseProvider entries on Linux

blocks:

• SR-1676 Build SourceKit on Linux

Issue Description:

The sourcekitd/sourcekitd.h header uses __has_feature(blocks) to only define block-based APIs on platforms that support them. For some of these APIs, function pointer equivalents are also defined.

However, much of the internal implementation of SourceKit uses the block-based APIs. Therefore, SourceKit cannot build on any platform that does not have blocks – specifically, it does not build on Linux.

The following block-based APIs need function pointer equivalents, and SourceKit implementation callsites to these functions should use the function pointer APIs instead:

• sourcekitd_set_interrupted_connection_handler needs sourcekitd_set_interrupted_connection_handler_f

• sourcekitd_variant_dictionary_apply needs sourcekitd_variant_dictionary_apply_f

• sourcekitd_variant_array_apply needs sourcekitd_variant_array_apply_f

• sourcekitd_send_request needs sourcekitd_send_request_f

• sourcekitd_set_notification_handler needs sourcekitd_set_notification_handler_f

• sourcekitd_set_uid_handlers needs sourcekitd_set_uid_handlers_f

As far as I know, adding a function pointer API for a block-based API looks something like the following, using sourcekitd_set_notification_handler as an example:

// Instead of a block `sourcekitd_response_receiver_t`, define a function `sourcekitd_response_receiver_f_t`.
// Because functions can't capture stack variables, it's passed a context pointer.
typedef void (*sourcekitd_response_receiver_f_t)(sourcekitd_response_t resp, void *context);
// Define another function that takes the new function pointer type.
void sourcekitd_set_notification_handler_f(sourcekitd_response_receiver_f_t receiver);

It might be a good idea to create sub-tasks for each of these, although I'd like to confirm that this is a reasonable direction before we do that.

[belkadan]

Do we want to remove blocks, or do we want to require a blocks runtime? We're going to need one on Linux anyway for Dispatch.

[modocache]

Oh I just tried http://stackoverflow.com/a/11097610/679254 and it worked great.

OK, I'll rephrase this task to involve adding libblocksruntime-dev as a dependency on the Swift README, and to update CMake to compile with -lBlocksRuntime. Thanks for the tip, @belkadan!

[modocache]

Submitted swiftlang/swift#2703

[modocache]

@belkadan: By the way, I'm curious for your thoughts on the swift-3.0 label, which I introduced in https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160516/000662.html. I've seen you "curate" labels in the past, so I hope I didn't step on your toes by creating one. I tagged this task as "swift-3.0" because it's a sub-task of https://bugs.swift.org/browse/SR-710, which is also marked "swift-3.0" – we want to be able to generate tests lists before shipping corelibs-xctest.

[belkadan]

I'm not sure if adding a blocks runtime is actually the answer we want. That's really a SourceKit question. @akyrtzi?

[akyrtzi]

I think this is up to the linux community, I'm not sure if requiring -lBlocksRuntime for building Swift is reasonable or onerous. At least you should make it optional and only linking it for SourceKit (meaning if someone only wants to build the compiler they should not need the block runtime).

[modocache]

Resolved via swiftlang/swift#2703