Fix build failure for importing NSUInteger as Int instead of the previously tested ok UInt

[phausler]

fixes rdar://problem/30899471

[phausler]

@swift-ci please test and merge

[phausler]

@jrose-apple Why would the previous PR build and test ok with the failure? It seems rather fishy.

[jrose-apple]

Terrible reasons. I tried to stir up interest to fix this but there didn't seem to be any takers.

[jrose-apple]

You may be able to avoid this in the future by adding [system] to Foundation's module map, so that it'll be treated as a system module no matter where you import it from.

[phausler]

Do I need to add [system] to the shim module map?

[jrose-apple]

...ah. Well, drat. Can you make a PR for that?

[phausler]

for adding [system] to the module map like this?

module _SwiftCoreFoundationOverlayShims [system] {
  header "CoreFoundationOverlayShims.h"
}

module _SwiftFoundationOverlayShims [system] {
  header "FoundationOverlayShims.h"
}

[phausler]

@swift-ci please test

[swift-ci]

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - afcd4103dd3e82749b00187f29834475b662c9d9
Test requested by - @phausler

[swift-ci]

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - afcd4103dd3e82749b00187f29834475b662c9d9
Test requested by - @phausler

[jrose-apple]

No, to change the importer to always import shims as system modules. The only reason we didn't was to catch warnings, but we can add a test that just uses -Wsystem-headers.

[phausler]

so you are saying instead that I should change them to be:

#define SHIMS_INCLUDE_FLAG "-isystem"

unconditionally no matter if it is NDEBUG or not?

[jrose-apple]

Yes, I think that's the right thing to do going forward.

[phausler]

so to be clear; the [system] change is inappropriate and should not be done then?

[phausler]

@swift-ci please test

[swift-ci]

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 7d516026d6cc6dea182f9570cc3bbe33fe1a7d96
Test requested by - @phausler

[swift-ci]

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - 7d516026d6cc6dea182f9570cc3bbe33fe1a7d96
Test requested by - @phausler

[phausler]

@swift-ci please test and merge

[gottesmm]

@phausler I think the OS X platform build failed again. The UI is just a bit messed up I believe. See:

https://ci.swift.org/job/swift-PR-osx/5888/

It looks like it is testing your latest commit and it failed.

[phausler]

@swift-ci please test and merge

[phausler]

Started by upstream project Swift Test and Merge build number 1566
originally caused by:
GitHub pull request #7979 of commit 125ef78a518e340a0bd6226bc6ecabfe478002fc, no merge conflicts.

that is the wrong sha1; it should be 00f3908
yet again another failure by the CI not picking up the right commits

[phausler]

the latest build is showing a build of 00f3908 which is correct
however this is now failing due to something that looks like something completely different?

/Users/buildnode/jenkins/workspace/swift-PR-osx/branch-master/swift/validation-test/compiler_crashers/28697-anonymous-namespace-findcapturedvars-checktype-swift-type-swift-sourceloc.swift:9:1: error: top-level statement cannot begin with a closure expression
09:58:04 {{extension{init(UInt=_=1 + 1 as?Int?Int){var f=nil?Int
09:58:04 ^

@jrose-apple should I just revert this whole ball of wax?

[jrose-apple]

It's possible we have a non-deterministic test. We should really try to get this in because it's blocking all our no-asserts builds. Let's just merge by hand once we pass a test.

@swift-ci Please smoke test macOS

[jrose-apple]

(I blame Past Me for leaving this trap in there.)

[dabrahams]

@jrose-apple I can force the merge even with tests failing if you think that's the right thing to do.

[jrose-apple]

It passed the smoke tests, so no force needed.

Thanks, Philippe!