sammccall added a comment. @dexonsmith thanks for sharing! Some initial thoughts since abstracting outputs is something we're starting to care about too...
This doesn't appear to be an extension point - you can write to an InMemoryFS or to real disk, but not to anything else. If we're going to add abstractions around output, I think they should support flexible use in libraries (which doesn't need to cost complexity here: FS vs MemoryFS vs custom storage can implement the same interface). With the right interface, I think this obviates the need for RequestedOutput and generalizes it - a caller can install an intercepting output backend that hooks certain paths and delegates the rest to the old backend. (Of course such a backend could be provided, but it gets the complexity out of the way of the core abstractions) I think the lifecycle and allowed operations on outputs would be clearer if an `Output` class was returned, with methods, rather than a stream + handle and various "free" functions (well, methods on OutputManager) than manipulate the handle. This would again make it easier to reason about what operations are part of a storage backend: there'd be some `OutputBackend` interface to implement, and it would hand out `Output` objects which again must be implemented. (This would be reminiscent of FileManager + vfs::FileSystem + vfs::File). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78058/new/ https://reviews.llvm.org/D78058 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
