[cfe-dev] Constant CFString merge

[Jean-Daniel Dupas]

Le 15 août 08 à 20:59, Daniel Dunbar a écrit :

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

> I think perhaps we should split the UTF-16 fix, which definitely  
> should be done
> for both, from the reorganization.
>
> - Daniel