Handle named pipes natively in SourceManager, removing a call to
SourceManager::overrideFileContents in
CompilerInstance::InitializeSourceManager. This is a blocker for
sinking the content cache down to FileManager (which will incidently
sink this new named pipe logic with it).
SourceManager usually checks if the file entry's size matches the
eventually loaded buffer, but that's now skipped for named pipes since
the stat won't reflect the full size. Since we can't trust
ContentsEntry->getSize(), we also need shift the check for files that
are too large until after the buffer is loaded... and load the buffer
immediately in createFileID so that no client gets a bad value from
ContentCache::getSize. FileManager::getBufferForFile also needs to
treat these files as volatile when loading the buffer.
Native support in SourceManager means that named pipes can also be
#included, and clang/test/Misc/dev-fd-fs.c was expanded to check for
that.
This is a new version of 3b18a594c7717a328c33b9c1eba675e9f4bd367c, which
was reverted in b34632201987eed369bb7ef4646f341b901c95b8 since it was
missing the SourceManager changes.
Would it make sense to do the diagnoseFileTooLarge check for both files and named pipes here unconditionally instead of having two separate checks? It appears that it shouldn't really matter if we check the ContentsEntry or the Buffer size for regular files, as their sizes are expected to match anyway.