[Support] Promote cl::StringSaver to a separate utility
authorSean Silva <chisophugis@gmail.com>
Fri, 15 Aug 2014 23:18:33 +0000 (23:18 +0000)
committerSean Silva <chisophugis@gmail.com>
Fri, 15 Aug 2014 23:18:33 +0000 (23:18 +0000)
commit3f8a26f6fe16cc76c98ab21db2c600bd7defbbaa
tree35214b51f596e781f955ba3f5b2ac788d64ed709
parentf11a5fc12db1d8c8008541db0b923ca42d7eb907
[Support] Promote cl::StringSaver to a separate utility

This class is generally useful.

In breaking it out, the primary change is that it has been made
non-virtual. It seems like being abstract led to there being 3 different
(2 in llvm + 1 in clang) concrete implementations which disagreed about
the ownership of the saved strings (see the manual call to free() in the
unittest StrDupSaver; yes this is different from the CommandLine.cpp
StrDupSaver which owns the stored strings; which is different from
Clang's StringSetSaver which just holds a reference to a
std::set<std::string> which owns the strings).

I've identified 2 other places in the
codebase that are open-coding this pattern:

  memcpy(Alloc.Allocate<char>(strlen(S)+1), S, strlen(S)+1)

I'll be switching them over. They are
* llvm::sys::Process::GetArgumentVector
* The StringAllocator member of YAMLIO's Input class
This also will allow simplifying Clang's driver.cpp quite a bit.

Let me know if there are any other places that could benefit from
StringSaver. I'm also thinking of adding a saveStringRef member for
getting a stable StringRef.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215784 91177308-0d34-0410-b5e6-96231b3b80d8
include/llvm/Support/CommandLine.h
include/llvm/Support/StringSaver.h [new file with mode: 0644]
lib/Support/CommandLine.cpp
unittests/Support/CommandLineTest.cpp