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

[Fangrui Song via llvm-commits]

MaskRay wrote:

> > Currently, raw_svector_ostream guarantees that the underlying vector is kept in sync. This was added in [[3d1173b](https://github.com/llvm/llvm-project/commit/3d1173ba1a53cab08ed2c33e47dd617df77a914b)]
> > 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))

Since there are so many failures, I agree that introducing a new name is safer.
`__asan_poison_memory_region` should reliably catch violations. asan builds will be slower, hopefully not a problem.

You might raise a topic on Discourse to raise attention and find maintainers to fix issues in their code:)

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