TestFoundation: use bridging for CFStringGetLength

[compnerd]

Rather than use CoreFoundation interfaces, use bridging more
aggressively to call the CoreFoundation methods. This reduces the
dependency on CoreFoundation for the test suite.

[compnerd]

@swift-ci please test

[compnerd]

@swift-ci please test

[compnerd]

@swift-ci please test

[compnerd]

@swift-ci please test

[compnerd]

@swift-ci please test macOS platform

[drodriguez]

I think this change might have broken Linux builds:

• https://ci-external.swift.org/job/oss-swift-RA-linux-ubuntu-16.04-android/2249/
• https://ci-external.swift.org/job/oss-swift-RA-linux-ubuntu-16.04-android-arm64/452/
• https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-16_04/3491/
• https://ci.swift.org/view/Packages/job/oss-swift-package-linux-ubuntu-18_04/1299/
• https://ci.swift.org/job/oss-swift-incremental-RA-linux-ubuntu-18_04/5376/

All of them finish with TestFoundation (ILLEGAL) just after Test Case 'TestNSString.test_substringFromCFString' started.

Looking at the test and the changes, it seems that the changes basically have remove the functionality that the test was testing for (doing a substring of a CFString, when after the changes, it is doing the substring of a NSString).

I think the problem comes from doing as NSString of an String in Linux, where a _nsObject might be necessary (but I'm not sure).

[drodriguez]

A little more information. The problem only happen in Release, or at least when -O is used. It seems to be some problem with the code generated for the accessors of stripCombiningMarks and (in my case) toUnicodeName. Seems that trying to access the former falls into the global initializer of the later. Even changing stripCombiningMark for stripDiacritics end up in the same.

The disassembly for stripDiacritics is the following:

disassemble -a 0x00007ffff62bfb27
libFoundation.so`NSString.StringTransform.stripDiacritics.unsafeMutableAddressor:
    0x7ffff62bfb10 <+0>:  pushq  %rbp
    0x7ffff62bfb11 <+1>:  movq   %rsp, %rbp
    0x7ffff62bfb14 <+4>:  leaq   0xa10e65(%rip), %rdi      ; globalinit_33_352A528E79284BBB704C1600E24E3449_token32
    0x7ffff62bfb1b <+11>: leaq   -0x32(%rip), %rsi         ; globalinit_33_352A528E79284BBB704C1600E24E3449_func32
    0x7ffff62bfb22 <+18>: callq  0x7ffff600e650            ; symbol stub for: swift_once
    0x7ffff62bfb27 <+23>: leaq   0xa10e5a(%rip), %rax      ; static Foundation.NSString.StringTransform.stripDiacritics : Foundation.NSString.StringTransform
    0x7ffff62bfb2e <+30>: popq   %rbp
    0x7ffff62bfb2f <+31>: retq

The disassemble for globalinit_33_352A528E79284BBB704C1600E24E3449_func32 is:

libFoundation.so`globalinit_33_352A528E79284BBB704C1600E24E3449_func32:
    0x7ffff62bfaf0 <+0>:  pushq  %rbp
    0x7ffff62bfaf1 <+1>:  movq   %rsp, %rbp
    0x7ffff62bfaf4 <+4>:  movq   0x9b1eb5(%rip), %rdi
    0x7ffff62bfafb <+11>: popq   %rbp
    0x7ffff62bfafc <+12>: jmp    0x7ffff62bfcb0            ; globalinit_33_352A528E79284BBB704C1600E24E3449_func21Tm

Which is the function that fails:

libFoundation.so`globalinit_33_352A528E79284BBB704C1600E24E3449_func21Tm:
    0x7ffff62bfcb0 <+0>:  pushq  %rbp
    0x7ffff62bfcb1 <+1>:  movq   %rsp, %rbp
    0x7ffff62bfcb4 <+4>:  cmpq   $0x0, (%rdi)
    0x7ffff62bfcb8 <+8>:  jne    0x7ffff62bfcbc            ; <+12>
    0x7ffff62bfcba <+10>: ud2
->  0x7ffff62bfcbc <+12>: ud2

Reverting this change until that problem can be investigated further might not be a bad idea.

[parkera]

@millenomi can you take a look?

[drodriguez]

I think the problem is in the library, not the tests. The <some CFString> as! String is invalid, but I don’t know why the compiler is not warning about it.