[llvm] [RFC][Support] Introduce buffered_svector_ostream (PR #97704)

[David Blaikie via llvm-commits]

dwblaikie wrote:

> Currently, raw_svector_ostream guarantees that the underlying vector is kept in sync. This was added in [3d1173b]
> Now, I'm unsure how to proceed:
> 
> * Add a new class `buffered_svector_ostream`, which is more efficient than raw_svector_ostream because it gives fewer guarantees, and do a mass refactoring (lot of churn)
> * Change semantics of `raw_svector_ostream`, causing less churn in-tree, but is likely to cause some bugs in the meantime (and will probably break some downstream users)
> * Something else?
> 
> Feedback/comments appreciated. :)

Given a 50% semantic failure (50% compilation failure I'd be more OK with - they're easy to identify and usually easy to fix - but semantic/test failures are harder to track down, especially the kind of failure this would produce - incorrect results) it seems pretty rough to impose this on clients.

I'd probably be inclined towards the "introduce a new name, migrate existing users, deprecate the old one, etc" but I guess it's still likely folks would just find-and-replace old name to new name and still have bugs. But at least they could then reduce the problem by bisecting through usage (migrating one usage at a time, see which one causes problems - or at least be able to bisect back to the change to their downstream code that causes problems, etc (similarly for upstream code - migrating one at a time would give a better chance to bisect back to the problem if a regression is found later, which I imagine would be likely))

https://github.com/llvm/llvm-project/pull/97704