This is the clang version of D33710.
Details
Diff Detail
Event Timeline
utils/TableGen/ClangOptionDocEmitter.cpp | ||
---|---|---|
272 | Had to make a copy into vector std::string because emitOptionWithArgs has another caller that passes a std::string vector. |
Few questions, but address them as you see fit.
utils/TableGen/ClangDiagnosticsEmitter.cpp | ||
---|---|---|
1280–1281 | Any reason (I'm guessing there is) not to do the str() on the + expression instead of the RHS? (seemed like you'd done that in other changes here, to minimize the string buffering/reallocation/etc by stringifying once at the top level of the expression) | |
utils/TableGen/ClangOptionDocEmitter.cpp | ||
86 | Does this need to be a std::string here? I'm not spotting any mutation (but I could well be missing it) of the value. Is it that StringREf doesn't support some of these substr - like operations? Oh, I guess it's that all of these operations want a std::string (for lookup in OptionsByName, for the result of string concatenation, etc). It'd still be marginally more efficient to not have to create a std::string up-front, I'd think, but syntactically annoying/verbose for all those uses? | |
272 | Would it be better/OK if the other caller was the one making the copy (it'd be cheaper to make a std::vector<StringRef> from a std::vector<std::string> than the other way around - but maybe the other caller is much hotter than this one?)? |
I assume you have checked that the tablegen output doesn't change. Apart from that I'm all for more StringRef and SmallStrings or even Twines where possible. So LGTM.
Any reason (I'm guessing there is) not to do the str() on the + expression instead of the RHS? (seemed like you'd done that in other changes here, to minimize the string buffering/reallocation/etc by stringifying once at the top level of the expression)