ClangImporter: enable -fblocks on non-Darwin platforms

[dgrove-oss]

What's in this pull request?

swift-corelibs-libdispatch requires block support when importing the dispatch
header files. This pull request enables block support in the ClangImporter
unconditionally on non-Darwin platforms (as is already done on Darwin platforms).

Without this change (or a more complex change that would look at the name
of the module being imported and only enable -fblocks if the module name was CDispatch),
the user must explicitly give -Xcc -fblocks as command line arguments to swiftc when
compiling any Swift program that imports Dispatch or Foundation on non-Darwin platforms.

Resolved bug number: (SR-)

---

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

A smoke test on macOS does the following:

1. Builds the compiler incrementally.
2. Builds the standard library only for macOS. Simulator standard libraries and
   device standard libraries are not built.
3. lldb is not built.
4. The test and validation-test targets are run only for macOS. The optimized
   version of these tests are not run.

A smoke test on Linux does the following:

1. Builds the compiler incrementally.
2. Builds the standard library incrementally.
3. lldb is built incrementally.
4. The swift test and validation-test targets are run. The optimized version of these
   tests are not run.
5. lldb is tested.

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.

We need to enable blocks support in the ClangImporter on
non-Darwin platforms for libdispatch (and transitively foundation).
The simplest way to do this is to just enable blocks unconditionally.

[dgrove-oss]

@parkera Here's the smallest change to avoid needing -Xcc -fblocks on Linux. I didn't attempt the more complex change that would make this conditional on the module being compiled, but if that is considered to be the right way to do it, I could attempt that (with a little guidance on how to actually get the module name down to the right place in the code to do the check).

[parkera]

cc @jrose-apple @DougGregor

[jrose-apple]

No, we should definitely turn on blocks all the time or not at all. In fact, I'd pull it out of the Darwin options into the common options instead. That said, are we going to try to make blocks-on-Linux have a Swift-compatible retain/release, or not? cc @rjmccall

[parkera]

We should do that (swift RR for Blocks), but what I think that means is pulling the C blocks runtime into the Swift runtime so that everything that links the Swift runtime gets these Swift-specific block behaviors.

(this is what I expect for Linux -- I'm not sure how that would work on Darwin, and I'm not sure if this would cause compatibility issues if people really wanted to use C blocks and pass them through to Swift without using the Swift runtime)

[dgrove-oss]

Modified as suggested by @jrose-apple to move adding -fblocks into the common options.

We resolved https://bugs.swift.org/browse/SR-2309 earlier today by embedding a copy of the blocks runtime into libdispatch (same runtime code as is already embedded in foundation). I believe that plus this change to the importer is good enough for Swift3.

For Swift 4 (or 3.x?) we really should get a common blocks runtime library with Swift RR

[jrose-apple]

Sorry, nitpicking, I meant to put it in the existing common section above, with -fsyntax-only and the rest.

[dgrove-oss]

no worries; fixed. Sorry for the extra churn.

[jrose-apple]

@rjmccall Did you have any comments here?

@swift-ci Please smoke test

[rjmccall]

It's kindof unfortunate that a Swifty libdispatch on Linux can't be written to just use Swift closure types, but we can address that in a future release.

[dgrove-oss]

I think the request to smoke test this pull request got lost when the CI system was down for the XCode upgrade. @jrose-apple Could you kick it again? Thanks

[jrose-apple]

Ah, sorry about that.

@swift-ci Please smoke test

[jrose-apple]

Looks like two XFAILed tests need to be enabled. :-) test/ClangModules/{cfuncs_parse.swift,cstring_parse.swift}

[dgrove-oss]

updated to remove the XFAIL annotation from the two test.

[jrose-apple]

@swift-ci Please smoke test

[jrose-apple]

GitHub status reporting seems to be broken, but the tests did start: Linux, OS X

[jrose-apple]

OS X test passed, Linux test failed in the same LLDB failure that's on master.

[RLovelett]

Is this expected to work with the embedded BlocksRuntime in libdispatch?

For example, the distro I'm using does not have a blocks runtime package. I've enabled the embedded blocks runtime, the one now in libdispatch master, and am able to compile libdispatch.

Will this change enable Swift to use that embedded blocks runtime?

[najacque]

@swift-ci Please smoke test

[najacque]

Ok, looks like that fixed it reporting status from ci. Let's see if tests pass now.

[CodaFi]

@swift-ci please smoke test OS X platform.

[jrose-apple]

and

@swift-ci Please smoke test Linux platform

[CodaFi]

Weird how just smoke test isn't enough to trigger CI for some of these.

[CodaFi]

Let's see about getting this through clean.

@swift-ci please smoke test Linux platform.

[CodaFi]

Fantastic!