This is an archive of the discontinued LLVM Phabricator instance.

Replace PrintStackTrace(FILE*) with PrintStackTrace(raw_ostream&)
ClosedPublic

Authored by zturner on Mar 4 2015, 11:07 PM.

Details

Summary

A FILE* method isn't as useful as an overload that takes an llvm::raw_ostream&. This way we can use raw_fd_ostream if we want the old behavior, or more commonly just llvm::errs() if we want to write to stderr. Plus, this adds the flexibility necessary to save the results to a string if we want to tee them to a log file as well as stderr, for example.

Note: This patch is currently untested on Linux and Mac. There should be no functional change, but I need to at least compile on Linux / Mac to make sure it's not broken. I plan to do this tomorrow. I'm mostly looking for comments on the general idea, because I don't expect this to be too controversial.

There is only 1 existing callsite of the FILE* method, which is in clang/CIndex.cpp. It calls PrintStackTrace(stderr). I will fix this to use PrintStackTrace(llvm::errs()) in a separate patch.

Diff Detail

Repository
rL LLVM

Event Timeline

zturner updated this revision to Diff 21258.Mar 4 2015, 11:07 PM
zturner retitled this revision from to Replace PrintStackTrace(FILE*) with PrintStackTrace(raw_ostream&).
zturner updated this object.
zturner edited the test plan for this revision. (Show Details)
zturner added reviewers: samsonov, rnk, chandlerc.
zturner added a subscriber: Unknown Object (MLST).
rnk edited edge metadata.Mar 5 2015, 10:54 AM

There is a functional difference between raw_ostream and FILE*. raw_fd_ostreams have their own buffering that doesn't mesh well with the buffering done with the C stdio implementation. I think CIndex.cpp and all that code makes sure to print with C stdio. We should be able to resolve this pretty easily by creating a raw_file_ostream adapter class, though.

I don't think it matters actually. The place in CIndex that was using this
was in cindex::Logger::~Logger(). It was using the `stderr' FILE*. stderr
is unbuffered for one thing, but anwyay as long as we change the rest of
the function to use llvm::errs() then everything should be fine.

Actually even better, it was *already* using llvm::errs() except for the
call to this function, where it passed in llvm::errs(). So this is
actually an improvement to the function, even if only a theoretical
improvement.

This revision was automatically updated to reflect the committed changes.