[all-commits] [llvm/llvm-project] 2d1338: Frontend: Delete output streams before closing Com...

[Duncan P. N. Exon Smith via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2d133867833fe8eb20c11377ff1221f71afc1db3
      https://github.com/llvm/llvm-project/commit/2d133867833fe8eb20c11377ff1221f71afc1db3
  Author: Duncan P. N. Exon Smith <dexonsmith at apple.com>
  Date:   2022-04-28 (Thu, 28 Apr 2022)

  Changed paths:
    M clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
    M clang/lib/Frontend/PrecompiledPreamble.cpp
    M clang/tools/driver/cc1_main.cpp

  Log Message:
  -----------
  Frontend: Delete output streams before closing CompilerInstance outputs

Delete the output streams coming from
CompilerInstance::createOutputFile() and friends once writes are
finished. Concretely, replacing `OS->flush()` with `OS.reset()` in:

- `ExtractAPIAction::EndSourceFileAction()`
- `PrecompiledPreambleAction::setEmittedPreamblePCH()`
- `cc1_main()'s support for `-ftime-trace`

This fixes theoretical bugs related to proxy streams, which may have
cleanups to run in their destructor. For example, a proxy that
CompilerInstance sometimes uses is `buffer_ostream`, which wraps a
`raw_ostream` lacking pwrite support and adds it. `flush()` does not
promise that output is complete; `buffer_ostream` needs to wait until
the destructor to forward anything so that it can service later calls to
`pwrite()`. If the destructor isn't called then the proxied stream
hasn't received any content.

This also protects against some logic bugs, triggering a null
dereference on a later attempt to write to the stream.

No tests, since in practice these particular code paths never use
use `buffer_ostream`; you need to be writing a binary file to a
pipe (such as stdout) to hit it, but `-extract-api` writes a text file
and the other two use computed filenames that will never (in practice)
be a pipe. This is effectively NFC, for now.

But I have some other patches in the works that add guard rails,
crashing if the stream hasn't been destructed by the time the
CompilerInstance is told to keep the output file, since in most cases
this is a problem.

Differential Revision: https://reviews.llvm.org/D124635