Introduce StringBuilder utility around raw_string_ostream

[Alp Toker]

On 12/06/2014 21:31, Chandler Carruth wrote:
>
> On Thu, Jun 12, 2014 at 5:21 PM, James Molloy <james at jamesmolloy.co.uk 
> <mailto:james at jamesmolloy.co.uk>> wrote:
>
>     FWIW, I like Alp's suggestion. There are a bunch of ways to do
>     string building in LLVM (Twine, raw_string_ostream,
>     std::stringstream). I'd appreciate a single mechanism for making
>     strings.
>
>
> But that's not what we would get.

I think you're taking an extreme and isolated view on this one Chandler. 
What James describes is exactly what we get from the proposed patch.

Where you see StringBuilder you get the assurance of safe string 
management. Use it as an ostream, and pop out a StringRef with 
equivalent lifetime to the object -- simple and efficient.

> As has already been discussed, the proposed interface would not 
> replace real use cases for raw_string_ostream

What are your parameters? The proposed patch includes 45 replacements of 
real use cases for raw_string_ostream. Each one is a win.

3/4 of those are heap allocation fixes.

Several are real bug fixes for output that's being truncated but isn't 
covered by tests. Do you really think we should keep the unsafe 
interface and wait for users to report each of these as PRs? (And 
there's more broken code in clang, which is what originally set me on 
this fix.)

I've gone ahead and produced examples of invalid string access, and 
demonstrated how the patch fixes each of these:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140609/221129.html

> , and it's going to be quite far from replacing the use cases of Twine.

The latest iteration of the patch is actually a very worthwhile Twine 
alternative if you're hitting string lifetime issues with that.

Anyway, shouldn't we be working to make the LLVM interfaces safer and 
more efficient for developers?

I think it'd be best if we stuck to the main issue and addressed any 
final review comments going forward. Listening to every viewpoint 
doesn't mean we can always satisfy them all.

Alp.

-- 
http://www.nuanti.com
the browser experts