Recently I found myself writing the following in a test case:
+// -- On Darwin, the first 4 GiB are unmapped: 0x7ffffffc
+// -- Otherwise, one can only assume the first page (4 KiB) is unmapped: 0xffd
+// CHECK-ios: i8* inttoptr (i64 2147483644 to i8*)
+// CHECK-macosx: i8* inttoptr (i64 2147483644 to i8*)
+// CHECK-watchos: i8* inttoptr (i64 2147483644 to i8*)
+// CHECK-darwin: i8* inttoptr (i64 2147483644 to i8*)
+// CHECK-objc-linux-gnu: i8* inttoptr (i64 2045 to i8*)
+// CHECK-native-linux-gnu: i8* inttoptr (i64 4093 to i8*)
+// CHECK-objc-windows: i8* inttoptr (i64 2045 to i8*)
+// CHECK-native-windows: i8* inttoptr (i64 4093 to i8*)
This feels needlessly complicated given that ObjC on non-Darwin platforms is "niche" to nonexistent, and given that disabling ObjC interoperability on Darwin means that the vast majority of Apple's frameworks become unusable.
What is the "plan" for ObjC support on non-Darwin platforms? Normally I don't like feature conflation, but in this case, conflating "is Darwin" with "supports ObjC" seems quite practical.
I don't speak for Apple or anyone else, but I'd strongly prefer to never support GNU Step in Swift. It would introduce a massive amount of complexity into the compiler and runtime (far more than in Clang) and there is no user base for it.
Do you think people would be open to replacing ObjC interop logic within the compiler with "is Darwin" checks? This would let us remove -enable-objc-interop and -disable-objc-interop from the frontend.
There are no plans to support other ObjC runtimes, at least from us. I would keep the flag disjoint from "is Darwin", though, since a non-ObjC-compatible Swift runtime on Darwin, although not maintained at this time, may be useful for things like server-side development on Mac hosts, in order to get closer behavior to Swift on other platforms.
I know @compnerd has been finding it very useful to be able to run tests for -enable-objc-interop on non-Darwin platforms, even if you can't actually execute anything. Makes it easier to tell if you've broken some ObjC thing. But we could probably invent some lit substitution like %darwin-target-triple that expands to the current target on Apple platforms and a dummy macOS on non-Apple platforms.
I also find it useful to have two RUN lines per test, one with ObjC enabled and one without. And yes, something like %darwin-target-triple would be preferable over -enable-objc-interop. Would people be open to %darwin-target-triple replacing -enable-objc-interop in the test suite?
I totally agree that it is more convenient to have two tests (w/wo objc) if testing ObjC specific behavior. Having a substitution is reasonable. However, there are differences in certain cases (e.g. section names) that are material to some IRGen tests. As long as those things are taken care of, I think that using the substitution is a great idea.
Unlike Chris, I'm not opposed to supporting ObjC interop on other platforms if somebody is willing to contribute and maintain that. I do think that we shouldn't try to enable ObjC interop in the default target ABI anywhere except Darwin, though; enabling ObjC interoperation with (say) GNUStep would be a variant, incompatible ABI.
Should we be pursuing ObjC interop? Swift should at some point supersede ObjC in all of its uses. We also know that the current ObjC interop for Darwin required a lot of people-hours to be invested in order to exist.
Unless there's something urgent and precious that we can get in other platforms from interacting with an ObjC runtime, I'd say let's not. There are already urgent and pressing issues outside of this topic, like the corelibs-foundation project and the cross-platform Swift tooling.
We already have pursued ObjC interop. It was a basic requirement of writing a programming language that works well with the Darwin platform APIs. And while it was, and continues to be, a huge project, the vast majority of that work is not Darwin-specific, and the parts that are are fairly self-contained. A few branches in IRGen and #ifs in the runtime are not a major burden.
Also, I'm not suggesting that anybody should be reassigned from their current tasks to work on GNUStep compatibility; I'm saying that if someone created a PR that added compatibility for other ObjC runtimes, that is a reasonable contribution that I would be willing to accept, provided they proved willing to maintain it.
Absolutely. If there was an ObjC runtime with invasively different interoperation requirements — e.g. if it didn't use reference-counting — then it would need to meet a much higher bar for us to consider supporting it.
Your response here illustrates a couple of things:
First. The project is and has been under active development for almost 20 years
Second. If you had even taken a cursory look at the codebase you would clearly see that there are Cocoa classes implemented in it.
I really hate it when people make unfounded and, worse, inaccurate statements about the project I have been the lead of for the last 8 years and part of almost since it’s inception.
Please get off this “GNUstep is nextstep” crap because it more closely follows cocoa. It is easy for people to read your message and believe what you’re saying than to actually take a look at the project itself!