Objc interop #12702
Objc interop #12702
Conversation
|
@swift-ci Please smoke test |
fjricci
force-pushed
the
objc_interop
branch
2 times, most recently
from
dc27eb5 to
676d296
Compare
|
@swift-ci please smoke test |
|
@swift-ci please smoke test |
|
@swift-ci please smoke test |
lib/ClangImporter/ClangImporter.cpp
Outdated
There was a problem hiding this comment.
This seems suspicious to me. Checking the implementation of clang::ObjCRuntime, iOS 2 is treated very differently from, say, iOS 7 (Swift's earliest iOS deployment target). Can you at least leave a note to re-inspect this later?
There was a problem hiding this comment.
I can update this to ios-7.0, I missed that version specifications are allowed.
There was a problem hiding this comment.
I'm not sure if that's the right answer either, but it's probably good enough for now.
lib/ClangImporter/ClangImporter.cpp
Outdated
There was a problem hiding this comment.
This part does only belong in the Darwin section, because the compiler version numbers are only set in official Apple builds. I'd rather not have people start using that for other purposes at this point in time.
There was a problem hiding this comment.
cc @compnerd - this is part of your change
There was a problem hiding this comment.
@jrose-apple sure, thats easy enough to move. However, that does seem useful to have in general. Any reason to not always have the swift compiler version made available?
There was a problem hiding this comment.
We don't set this value at all for open source builds. (This is the "900.0.30" thing, not "4.0.2".)
There was a problem hiding this comment.
We barely even use it at Apple; there's a chance we might take it out altogether.
There was a problem hiding this comment.
@jrose-apple SGTM, I'll remove that
There was a problem hiding this comment.
EnableObjCInterop won't be on for these invocations, though, right?. They're all using -target and there's no argument for -enable-objc-interop in swift-ide-test.
There was a problem hiding this comment.
Hrm, I'm not super familiar with the code yet, but it looks to me like EnableObjCInterop is actually defaulted to true in LangOptions.h. A few of the tools default it to isOSDarwin() (Frontend/CompilerInvocation.cpp, sil-llvm-gen, sil-opt), but swift-ide-test doesn't modify the value. Not sure the best approach here, since swift-ide-test doesn't look like it plays much with flags currently.
There was a problem hiding this comment.
Interesting. I feel like swift-ide-test should follow the other tools to defaulting it based on the target triple and allowing that to be overridden.
fjricci
force-pushed
the
objc_interop
branch
2 times, most recently
from
c4f7530 to
8ca2803
Compare
|
@swift-ci please smoke test |
There was a problem hiding this comment.
Please respect both options in all modes. The target just chooses the default.
(I know this has the same effect assuming people don't pass both flags, but it's not a good way to write it, in that I didn't realize that immediately.)
There was a problem hiding this comment.
I believe that this already handles all the cases except the case where both flags are set simultaneously. I can handle it more explicitly though if that's preferred.
Current behavior:
darwin + disable = disabled
darwin + enable = enabled (by virtue of disable being unset and falling back to the default)
non-darwin + enable = enabled
non-darwin + disable = disabled (by virtue of enable being unset and falling back to the default)
Not sure what we'd want to do in the case where somebody sets both (or if we even need to handle that).
There was a problem hiding this comment.
(disregard my comment, looks like we passed each other while typing)
|
@swift-ci please smoke test |
Select the language for the clang importer based on the `-enable-objc-interop` flag rather than target. This paves the road to enabling ObjC tests on non-Darwin targets as well as building on Darwin without ObjC interop.
This allows objc interop to be tested on non-darwin platforms. The iOS runtime is used because the abi is the same as the macOS abi, but without fragility concerns.
This adds a -disable-objc-interop flag to allow objc-interop to be disabled, and an -enable-objc-interop flag to allow objc-interop to be enabled. Objc interop will default to enabled on darwin, and disabled on other platforms.
|
@swift-ci please smoke test |
| // TODO: Investigate whether 7.0 is a suitable default version. | ||
| if (!triple.isOSDarwin()) | ||
| invocationArgStrs.insert(invocationArgStrs.end(), | ||
| {"-fobjc-runtime=ios-7.0"}); |
There was a problem hiding this comment.
This will let us make some progress, but eventually you'll need to decide which Objective-C runtime(s) to target outside of Darwin. For example, Clang supports GNUstep, and one could imagine surfacing Clang's understanding of the Objective-C runtime so that Swift could build on top of it (rather than duplicating it).
There was a problem hiding this comment.
I don't have much time to work on it, but I'm happy to provide advice to anyone who wants to add support for the GNUstep runtime (and add any missing runtime features that Swift needs).
There was a problem hiding this comment.
Until we get GNUStep to the point where the object layout works in a compatible manner (or change the swift object layout), I think that not permitting control over the runtime is quite reasonable.
There was a problem hiding this comment.
Are Swift's requirements documented anywhere?
There was a problem hiding this comment.
I don't think so. Off the top of my head two of the biggest requirements are:
- Swift wants to generate ObjC class structures (at compile time and at runtime) with additional Swift data prepended and appended.
- Swift wants control of a bit in the ObjC class structure in order to mark ObjC classes that are also Swift classes.
There was a problem hiding this comment.
The second requirement is easy - we have a flags field and can reserve a bit for Swift to use.
The first is a bit harder because the clang generates these structures without providing hooks to add fields. The structure is defined here.
This will change in the next version of the runtime, and the current prototype for the new ABI would make this more difficult, because it puts all of the class structures in a section and the loader in the runtime expects them to be contiguous in memory, so adding other fields would mean that the runtime would need to be aware of the structure.
I'm also rearranging some of the fields to split the structure into ones that are likely to be modified at run time and ones that aren't, based on feedback from Microsoft that the runtime generates more CoW faults at start than they'd like - I'm not sure where the Swift fields would like to go, but if it's on the immutable part then that's probably easier, because that will be reachable via a pointer to the start from the mutable part, and that can easily be a pointer to the middle of a larger structure.
6 participants
This PR includes the changes made by @compnerd in #12657 to support objc interop, in addition to a patch to allow objc interop testing on non-darwin platforms.