One problem here is how to handle emission of constant CFStrings when
not in Objective-C mode.
I don't really want to always have a CGObjCRuntime object around, because
the runtime is likely to want to add data to the module which should only
happen for ObjC files, and conditionalizing this in the CGObjCRuntime is
In the patch, the obj-c runtime is not required. The implementation is splitted into ASTContext (for the type declaration) and CodeGen (for GetAddrOfConstantCFString()).
The apple objc runtime only call GetAddrOfConstantCFString(), and when compiling a C file, you don't have to create an objc runtime, you can just call GetAddrOfConstantCFString() of CodeGenModule.
This made me think that perhaps having separate methods is not so bad.
There is also the complexity that gcc supports several options which change
how constant strings are handled, but these options should probably not
conflict with how __builtin___CFStringMakeConstantString is implemented.
I'm not yet sure how these options interact, however.
I don't know a lot of options that change the way objc/cf strings are generated. I'm only aware about:
Both functions does not change the way constant strings are created, but define if an alternative way should be used (instead of GetAddrOfConstantCFString()).
If the first option (-fconstant-cfstrings ) is not defined, the CFSTR macro definition create function call instead of call to the builtin function.
The second option:
- if -fconstant-cfstrings is specified, it override this setting, and constant cfstrings are generated.
- if -fconstant-cfstrings is not specified, obj string generation should create a constant string specific to each runtime (NSConstantString by default for the next runtime), so it does not use constant CFString generation at all.
And so, I don't see any option that change the way GetAddrOfConstantCFString() should behave (but maybe I miss something).