LLP64 targets and integral types

windows
foundation
(Joe Groff) #21

Are there instances where we would fail to import a CF_ENUM as an enum into Swift and just leave it as its underlying type? Maybe the Foundation code is incidentally relying on some gap in the compiler's Clang importer which we accidentally plugged by fixing the mapping of CFIndex to Int on Windows.

1 Like
(Jordan Rose) #22

Oh shoot, that's exactly what it is. CF_ENUM only works the nice way when enums-with-underlying-types are supported. That works on Apple platforms, because it's an Objective-C extension, and it works on Windows because it's a Microsoft C extension, but it doesn't work on Linux, and so the macro falls back to "declare an anonymous enum and then a typedef of the right size, so that at least we control the ABI correctly".

I think you'll have to talk to the Foundation folks about what the best thing is to do here. The least invasive thing is to say that corelibs-foundation's definition of CF_ENUM should act like enums-with-underlying-types are not supported in non-ObjC mode on Windows. The best thing would be to get enums-with-underlying-types on Linux somehow at some point (which has been talked about on cfe-dev as a general extension Clang could support), but that's very clearly going to be a source compat issue for us.

1 Like
(Joe Groff) #23

Optimistically, it might be an acceptable source break for Linux since more of the ecosystem is native Swift, and the breakage is hopefully limited to packages at the C-Swift frontier like Foundation. Could we pursue a targeted solution for CF_ENUM/NS_ENUM macros to pick up the underlying type from the typedef when the target language mode doesn't support underlying types? That should only impact Foundation, which hopefully would be able to deal with the breakage, and seems like a net compatibility benefit, since it would make the underlying CF interfaces more similar on Linux and Darwin.

(Saleem Abdulrasool) #24

The idea of the extension basically came down to ideology. How do we prevent the leak of the extension when explicitly looking for standard compliant code. Adding a variant was my preferred solution, though some others didn't like that. However, we do have a way to control GNU extensions, and this seems reasonable to have a control as well. The question is, are there other extensions that we will need? If not, then it is probably easier to just add a feature flag (-ftyped-enums?) rather than add a higher level control.

@Joe_Groff, I completely agree that the source level compatibility is preferable at the cost of an extra flag.