Make bridged String and collection types conform to CVarArg.

[jckarter]

This allows String, Array, Dictionary, and Set to be passed as variadic arguments to Cocoa APIs like NSLog, NSPredicate, stringWithFormat:, etc. rdar://problem/27651717

[jckarter]

@swift-ci Please smoke test

[jckarter]

@gribozavr Do you mind reviewing?

[jrose-apple]

How about the Foundation-level bridged types? What about Linux? cc @phausler

[phausler]

NSLog is omitted since print is preferred.
NSString has the method:

public convenience init(format: String, arguments argList: CVaListPointer) {
        let str = CFStringCreateWithFormatAndArguments(kCFAllocatorSystemDefault, nil, format._cfObject, argList)!
        self.init(str._swiftObject)
    }

which defers to CF, but there is no adoption else wise.

[jckarter]

@jrose-apple We can add more conformances easily enough. String is by far the most important. This has no impact on Linux, since it would already have not worked before, but maybe corelibs could add the same conformances for parity.

[jckarter]

@shahmishal Linux build seems to be broken by an LLVM change:

ninja: error: '/home/buildnode/jenkins/workspace/swift-PR-Linux-smoke-test/buildbot_linux/llvm-linux-x86_64/lib/libLLVMGlobalISel.a', needed by 'bin/swift', missing and no known rule to make it

[rjmccall]

Is this a good idea for String? It's not obvious that converting to an NSString is better than, say, converting to const char*.

[jckarter]

@rjmccall It mirrors our Swift 2 behavior, where strings in CVarArg context would implicitly convert to NSString. The CVarArg protocol doesn't provide any safe way to get a char* out of a String that I can think of either.

[rjmccall]

Alright, fair enough.

[gribozavr]

I'm not sure this is the right thing to do. Do people actually expect that String is passed as NSString, or do they prefer char *? Especially on Linux.

Also, please add tests for all new APIs and new usecases (e.g., passing an Array as a vararg).

[jckarter]

@gribozavr This preserves the Swift 2 behavior for Darwin, and this never worked for Linux. I don't see how we can realistically support %s at all without a major redesign of CVarArg, and I doubt that's ever in the cards, since the affected APIs aren't particularly idiomatic to begin with.

[jckarter]

@gribozavr The behavior should also already be exercised by existing tests where I've rolled back as conversions that were made necessary by the original implementation of SE-0072.

[gottesmm]

@swift-ci Please smoke test

[jckarter]

Looks like we never really exercised (NS)Array or Dictionary varargs. Added a test for that.

[gottesmm]

(Just curious if the linux smoke test is fixed, Mishal cleared the workspace)

[gribozavr]

The behavior should also already be exercised by existing tests where I've rolled back as conversions that were made necessary by the original implementation of SE-0072.

We have a policy in the library that we don't add APIs without directed tests for them. Incidental tests can come and go as those files are refactored. We can't rely on them.

[gribozavr]

@gribozavr This preserves the Swift 2 behavior for Darwin, and this never worked for Linux.

I understand, but we are trying to do the right thing, and not just preserve the behavior. If we were trying to preserve the behavior, we would not do id-as-Any.

[gribozavr]

Please add a better, more descriptive test or at least a comment about what is important about this line. It is not clear what this line is testing.

[jckarter]

@gribozavr OK, I added comments to the tests.