SR-3658 – Fix error in importing Foundation

[swizzlr]

SR-3658 – Fix error in importing Foundation under Linux. This commit may resolve the described error.

Honestly, I have no idea if this'll work. My machine does not have the horsepower to compile this project, but at the very least maybe the CI can take a crack at it. From a cursory review this line seems unnecessary.

[parkera]

We do need Block.h for CF itself, but we may not need it to be in a header that is part of the module map. Basically - anywhere we call Block_copy and friends will still need this include.

[e78l]

From grep, Block.h seems to be included in these files:
./CoreFoundation/Base.subproj/CFBase.h:72:#include <Block.h>
./CoreFoundation/Base.subproj/CFUtilities.c:57:#include <Block.h>
./CoreFoundation/Collections.subproj/CFBasicHash.c:14:#include <Block.h>
./CoreFoundation/RunLoop.subproj/CFRunLoop.c:106:#include <Block.h>

I tried adding to build.py:
'-I./closure',

But then xctest had a problem too, so I just copied Block.h into an existing include path.

[swizzlr]

Thing is, this was working in 3.0 - it was a commit migrating the Sierra source dump that introduced the offending code - but CF has had blocks for years now?

Or is it the case that CFBase, by including Blocks.h in the header, and not source files, is trying to make Swift eventually include Blocks.h, which isn't used under Linux?

[parkera]

Let's try this: it'll tell us where we need the include for real.

[parkera]

@swift-ci please test

[parkera]

What's interesting is that the include has been in the Darwin CFBase.h for quite some time; so it's surprising that it was introduced here with the Sierra merge.

[swizzlr]

Jesus.

[parkera]

I think it was probably removed for this very reason in our original CF import into this project, but then put back with the rest of the Sierra fixes. We'll need to make sure it stays out in the future.

[parkera]

@swizzlr will you put a PR up for the swift-3.1 branch with this change?

[parkera]

Sorry, I mean the master branch.

[thawkins]

Can we please get this fix merged into the master, the master wont build at the moment because of this.

[swizzlr]

Wait, don't we have build snapshots for Swift 3.1?

[thawkins]

Im trying to build from git, should master not be always buildable?

…

On Thu, Feb 2, 2017, 22:23 Thomas Catterall ***@***.***> wrote: Wait, don't we have build snapshots for Swift 3.1? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#843 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAA4yX7ZwpDAD46GkHxhXKxyOux3RVJ5ks5rYebFgaJpZM4LvVvi> .

[thawkins]

folks im still seeing this on the swift-3.1-branch

../build/buildbot_linux/foundation-linux-x86_64/Foundation/usr//lib/swift/CoreFoundation/ForSwiftFoundationOnly.h:265:60: note: insert '_Nonnull' if the array parameter should never be null
CF_EXPORT void _cf_uuid_unparse_upper(const _cf_uuid_t uu, _cf_uuid_string_t out);
^
_Nonnull
CoreFoundation/Collections.subproj/CFBasicHash.c:14:10: fatal error: 'Block.h' file not found
#include <Block.h>
^
18 warnings and 1 error generated.

[thawkins]

In order to get it to compile i had to insert the following between update-checkout and build-script

sed -i '/#include <Block.h>/d' swift-corelibs-foundation/CoreFoundation/Base.subproj/CFBase.h
sed -i 's/#include <Block.h>/#include <closure/Block.h>/g' swift-corelibs-foundation/CoreFoundation/Collections.subproj/CFBasicHash.c
sed -i 's/#include <Block.h>/#include <closure/Block.h>/g' swift-corelibs-foundation/CoreFoundation/RunLoop.subproj/CFRunLoop.c