Constant CFString merge

Clang Frontend
1

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
somewhat gross.

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 think perhaps we should split the UTF-16 fix, which definitely should be done
for both, from the reorganization.

- Daniel

2

I can't speak for the Apple Runtime, but the GNU and Étoilé runtime backends only emit stuff for Objective-C features that are used. If you compile a file as a .c or .m file you will get the same results.

For Objective-C strings in the GNU runtime, this will emit a hook into the runtime library because it allows you to replace the constant string class at load time. If the NeXT runtime uses a constant symbol to do this then it should not emit anything Objective-C specific if you just use the constant Objective-C string method.

David

3

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
somewhat gross.

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:

-fconstant-cfstrings
and
-fconstant-string-class

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).