[triplef]

Companion to gnustep/libs-base@4fae78775, which implemented CFRunLoopAddCommonMode(), CFRunLoopCopyAllModes() and CFRunLoopCopyCurrentMode() in Base. With this change, both libraries export these functions with equivalent behavior, so it doesn't matter which library's copy a caller binds to:

• corebase functions: when passed an Objective-C object (e.g. an NSRunLoop from -getCFRunLoop), they dispatch to the corresponding NSRunLoop methods via CF_OBJC_FUNCDISPATCHV, like the CFRunLoopTimer functions already do. Without the ObjC runtime they keep only the native path.
• New NSCFRunLoop bridge class: implements -addCommonMode:, -allModes and -currentMode for CFRunLoopRefs, so Base's functions (which send those messages) work on corebase run loops too. It calls private implementations rather than the public functions, because those could resolve to Base's copy and recurse.
• NSCFType.m: fixes requiredClasses, which was not updated when NSCFDate was added (13 classes call NSCFInitialize(), but the count was 12). It is now 14, including the new class.

Testing

Tested on Windows (MSVC ABI, clang, libobjc2) with the new Tests/CFRunLoop/bridge.m:

• With both libraries linked in either order, there are no duplicate-symbol link errors. The executable imports the functions from corebase or from Base depending on link order, and the tests pass with both.

Not yet tested: the NSCFRunLoop path (Base's functions on a corebase run loop). CFRunLoop support is disabled on Windows, so CFRunLoopGetCurrent() returns NULL there, and the test marks that part as hopeful. Draft until it has run on Linux.

[triplef]

The gnustep-1.9 tests were failing because autoreleasing any bridged CF object seems to crash on gnustep-1.9. The minimal reproduction is [(id)CFArrayCreate(NULL, NULL, 0, &kCFTypeArrayCallBacks) autorelease]. Work around by converting to NSArray.

[rfm]

OK. Thanks.