[ClangImporter] Handle NS_TYPED_ENUMs of NSUIntegers in non-system headers

[jrose-apple]

The special rule for NSUInteger in system headers was colliding with the behavior of NS_TYPED_ENUM (swift_newtype/swift_wrapper). Let NS_TYPED_ENUM take precedence here.

(I also future-proofed this for BOOL and Boolean, but those don't NS_TYPED_ENUM correctly right now for another reason: Bool is bridged to Objective-C via NSNumber, but ObjCBool is not, even though it could be.)

rdar://problem/50076612

[jrose-apple]

@swift-ci Please test

[jrose-apple]

@swift-ci Please test source compatibility

[rjmccall]

Seems reasonable.

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 3498ca8

[jrose-apple]

@swift-ci Please test Linux

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 3498ca8

[jrose-apple]

@swift-ci Please test Linux

[compnerd]

Seems reasonable to me as well. The cleanup is nice.

[davezarzycki]

Hi @jrose-apple – How was this tested on Linux? I'm seeing lots of crashes in the test suite in free() (using jemalloc).

[jrose-apple]

Hm. I wouldn't expect it to affect Linux at all—it's supposed to be a no-functionality-change change for everything except NSUInteger. How'd you pinpoint this PR as the cause?

[davezarzycki]

I have a script that runs every 12h that does a clean [unified] build. If that succeeds, then a local “branch” is updated to the mark the last known good commits. This makes bisecting fairly painless when something doesn’t work. In this case, and because of the weekend, only two pull requests existed between the “last good” commit and the “first known bad” commit (this pull request). I did a clean build / test of the PR merge before this PR and that succeeded, therefore this PR is to “blame”.

[davezarzycki]

@jrose-apple – For reference: http://znu.io/4jordan.txt

[davezarzycki]

FWIW – This appears to only happen with optimized builds. Maybe garbage is being passed to free() that is coincidentally a nullptr in a debug build?

[davezarzycki]

Hi @jrose-apple – My sincerest apologies. The problem commit is on the clang side: apple/swift-clang#304

[jrose-apple]

Whew! I was set to do a lot of headscratching debugging here, since I can certainly believe that a seemingly-NFC change would cause problems. I reverted the Clang commit, since it's a change that matches the backtrace.

[davezarzycki]

Ya, sorry, the swift-llvm/swift-clang stable branches tend to be um, stable, and updated infrequently, so I didn’t even think about the fact that my script would reset swift-clang back to a known good state too.