Documentation: Update CMake.md to use the ABI entry point

[ADKaster]

The SwiftPM entry point is unstable and the new ABIv0 entry point has already been added to the library.

Motivation:

Using the SwiftPM entry point when building tests from a CMake project as recommended in the documentation is outdated and unwise.

Modifications:

Replace the example with one using the new ABIv0 entry point.

Result:

CMake projects should stop relying on the SwiftPM entry point.

Checklist:

• Code and documentation should follow the style of the Style Guide.
• If public symbols are renamed or modified, DocC references should be updated.

[ADKaster]

cc @compnerd

[ADKaster]

Hm. Chatting with Jonathan on Slack some more, it seems like the fact that this works with the Swift OSS toolchain on linux is a toolchain bug: we shouldn't be able to access the private module from user code.

Another alternative (with -enable-experimental-feature Extern) looks like this:

import Foundation

typealias EntryPoint = @convention(thin) @Sendable (_ configurationJSON: UnsafeRawBufferPointer?, _ recordHandler: @escaping @Sendable (_ recordJSON: UnsafeRawBufferPointer) -> Void) async throws -> Bool

@_extern(c, "swt_abiv0_getEntryPoint")
func swt_abiv0_getEntryPoint() -> UnsafeRawPointer

@main struct Runner {
    static func main() async throws {
        let configurationJSON: UnsafeRawBufferPointer? = nil
        let recordHandler: @Sendable (UnsafeRawBufferPointer) -> Void = { _ in }

        let entryPoint = unsafeBitCast(swt_abiv0_getEntryPoint(), to: EntryPoint.self)

        if try await entryPoint(configurationJSON, recordHandler) {
            exit(EXIT_SUCCESS)
        } else {
            exit(EXIT_FAILURE)
        }
    }
}

[grynspan]

So, yes-and-no. As we talked about in Slack, it's a bug that any @_spi content is available in the Swift toolchain right now and it's going to get removed in the future.

For the moment, code should either use dlsym()/GetProcAddress() or, if a little more adventurous, use the experimental @_extern(c) to call swt_abiv0_getEntryPoint(), then load the SwiftCC entry point from there. (@_silgen_name could be used too, but technically the calling conventions are incompatible, so caveat codor.)

We're still looking at how to expose these symbols in a way that makes it easy for test tools/harness authors but doesn't make the symbols visible to test authors by default. We're looking at adding a dedicated target in the package (if we can do so without requiring building the whole library from source) or creating a separate swift-testing-tools-support package, among other options.

[grynspan]

You can leave this line out and just pass nil if you're not actually going to use it. :)