[PATCH] Allow for the use of StringRef command line options instead of cl::opt<std::string>

[Puyan Lotfi]

This sounds like a workable compromise.
To avoid leaking how about a CommandLine.cpp handled string pool that allocates copies on demand (specified maybe by an optional flag to ParseCommandLineOptions/ParseEnvironmentOptions) but also has the option of flushing/deallocating the pool?

-Puyan

On Aug 15, 2013, at 1:47 PM, Chris Lattner <clattner at apple.com> wrote:

> 
> On Aug 14, 2013, at 4:06 PM, Puyan Lotfi <plotfi at apple.com> wrote:
> 
>> Oh wow. I see that.
>> 
>> I am not completely sure how the char* arrays would get handled this way.
>> I did not make any clang modifications in this patch (although since clang is using the cl library it is affected) but I noticed that the use of cl:: in the llvm source tree made use of global cl::opt variables that specify the opt type.
>> I don’t see that in the files handling the -mllvm options; I’ll have to look at the CommandLine.cpp code a little more closely to be sure in this case that the char*’s aren’t being implicitly put into StringRefs that might have their data pointers deallocated after cl::ParseCommandLineOptions() is called. 
> 
> After thinking about it for a bit, how about we go with this approach:
> 
> 1. Document ParseCommandLineOptions/ParseEnvironmentOptions to only work with strings that live forever in CommandLine.h
> 2. Change clang to leak (or store globally) the strings that are affected.
> 
> I don't think it is worth designing a context system or anything like that to handle this case. 
> 
> -Chris