diff options
author | Sean Silva <chisophugis@gmail.com> | 2014-08-15 23:18:33 +0000 |
---|---|---|
committer | Sean Silva <chisophugis@gmail.com> | 2014-08-15 23:18:33 +0000 |
commit | 42ec6fdf58f4226467aaecd07e2c7bfa0d667186 (patch) | |
tree | 3121b33f6a4b3a7be72bcf1f10ed08ea4b683920 /llvm/lib/CodeGen/MachineFunction.cpp | |
parent | e8bf7496531a08f3fc8dbef64dc4c5245f788d65 (diff) | |
download | llvm-42ec6fdf58f4226467aaecd07e2c7bfa0d667186.zip llvm-42ec6fdf58f4226467aaecd07e2c7bfa0d667186.tar.gz llvm-42ec6fdf58f4226467aaecd07e2c7bfa0d667186.tar.bz2 |
[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.
llvm-svn: 215784
Diffstat (limited to 'llvm/lib/CodeGen/MachineFunction.cpp')
0 files changed, 0 insertions, 0 deletions