FileManager: Improve the FileEntryRef API and customize its OptionalStorage

Authored by dexonsmith on Oct 19 2020, 8:36 PM.


FileManager: Improve the FileEntryRef API and customize its OptionalStorage

Make a few changes to the FileEntryRef API in preparation for
propagating it enough to remove FileEntry::getName().

  • Allow FileEntryRef to degrade implicitly to const FileEntry*. This allows functions currently returning const FileEntry * to be updated to return FileEntryRef without requiring all callers to be updated in the same patch. This helps avoid both (a) massive patches where many fields and locals are updated simultaneously and (b) noisy incremental patches where the first patch adds getFileEntry() at call sites and the second patch removes it. (Once FileEntryRef is everywhere, we should remove this API.)
  • Change operator== to compare the underlying FileEntry*, ignoring any difference in the spelling of the filename. There were 0 users of the existing function because it's not useful. In case comparing the exact named reference becomes important, add/test isSameRef.
  • Add == comparisons between FileEntryRef and const FileEntry * (compares the FileEntry*).
  • Customize OptionalStorage<FileEntryRef> to be pointer-sized. Add a private constructor that initializes with nullptr and specialize OptionalStorage to use it. This unblocks updating fields in size-sensitive data structures that currently use const FileEntry *.
  • Add OptionalFileEntryRefDegradesToFileEntryPtr, a wrapper around Optional<FileEntryRef> that degrades to const FileEntry*. This facilitates future incremental patches, like the same operator on FileEntryRef. (Once FileEntryRef is everywhere, we should remove this class.)
  • Remove the unncessary const from the by-value return of FileEntryRef::getName.
  • Delete the unused function FileEntry::isOpenForTests.

Note that there are still FileEntry APIs that aren't wrapped and I
plan to deal with these separately / incrementally, as they are needed.

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