[cfe-dev] Constant CFString merge

[Daniel Dunbar]

Okay, that makes sense. The only issue then is that the runtime doesn't
get control over what the constant string class reference is called, but since 
GNU and NeXT both use the same name that doesn't seem to be an issue.

RE: The patch:

(1) In ASTContext::getCFConstantStringType there is really no need to use
a SmallVector here, even if the size is changing by one. Also some of
the comments re: the type are incorrect... and why did you change the ones
you did (the str I understand, but why unsigned -> signed or const int* -> int*)?

I think it makes more sense to change this file when someone does UTF-16
support.

(2) The NeXT runtime should still set the section on constant cfstrings.

 - Daniel



----- Original Message ----
From: Jean-Daniel Dupas <devlists at shadowlab.org>
To: Daniel Dunbar <daniel at zuster.org>
Cc: cfe-dev Developers <cfe-dev at cs.uiuc.edu>
Sent: Friday, August 15, 2008 1:40:01 PM
Subject: Re: [cfe-dev] Constant CFString merge


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