[llvm] Add thread-local overrides for `llvm::errs()` and `llvm::outs()`. (PR #90374)

[Chandler Carruth via llvm-commits]

chandlerc wrote:

> I think it would also be important for `llvm::CrashRecoveryContext` to persist the stream overrides into the inner thread.

Good idea, done and tested that this works.

> I worry that a tool like this would disincentivize fixing/improving existing libraries that could/should take a stream as a parameter... - so I'm weakly not in favor of this, in that I'd rather see the library improvements... but no doubt there are some hard cases.
> 
> Are the cases you have in mind in-tree/could you give a rough overview of the challenges/why this is the better path?

Yeah, TBH, this isn't my favorite approach either. But I don't really know how to achieve the other approaches in a reasonable timeframe.

The code I specifically am hitting this in is Clang's Driver and Frontend library which have a bit over 60 uses of `llvm::errs()` at a quick count. If it were just updating all of those cases, maaaaaybe I could manage to do it, but the real issue is that all of these are behind layers and layers of APIs across the driver and frontend library that would need to be updated to thread a stream parameter through. In some places, there is a diagnostic engine available, but the uses of `llvm::errs()` don't seem to really map well into that abstraction, and doing so would likely break users expecting the output in its exact form.

But this is a pretty pervasive challenge when using both Clang and LLVM as libraries. For example, Clang has 500 some uses of `llvm::errs()` through out its `lib` directory, some in almost every library. A quick skim didn't seem to show many that were really utility code or outside of what a library user might encounter. LLVM itself has over 100 uses in `lib/Transforms`, where similarly it would be nice for a library user to be able to avoid directly writing to stderr, and it again seems difficult to imagine plumbing streams through all the APIs.

Long term, the right thing is definitely to try to avoid using these in code paths that are intended to be library-used, and instead to build some better mechanism. But I think that will be the work of years, and I'd somewhat like to have the flexibility of controlling this in the mean time.

Dunno, curious what others think here.

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