[all-commits] [llvm/llvm-project] e78c80: [clang] SourceManager: fix at SourceManager::getFi...

[Ivan Murashko via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e78c80e3d622d455934102dabd765a60ac917739
      https://github.com/llvm/llvm-project/commit/e78c80e3d622d455934102dabd765a60ac917739
  Author: Ivan Murashko <ivanmurashko at fb.com>
  Date:   2022-08-10 (Wed, 10 Aug 2022)

  Changed paths:
    M clang/lib/Basic/SourceManager.cpp

  Log Message:
  -----------
  [clang] SourceManager: fix at SourceManager::getFileIDLoaded for the case of invalid SLockEntry

There is a fix for the search procedure at `SourceManager::getFileIDLoaded`. It might return an invalid (not loaded) entry. That might cause clang/clangd crashes. At my case the scenario was the following:
- `SourceManager::getFileIDLoaded` returned an invalid file id for a non loaded entry and incorrectly set `SourceManager::LastFileIDLookup` to the value
- `getSLocEntry` returned `SourceManager::FakeSLocEntryForRecovery` introduced at [D89748](https://reviews.llvm.org/D89748).
- The result entry is not tested at `SourceManager::isOffsetInFileID`and as result the call `return SLocOffset < getSLocEntryByID(FID.ID+1).getOffset();` returned `true` value because `FID.ID+1` pointed to a non-fake entry
- The tested offset was marked as one that belonged to the fake `SLockEntry`

Such behaviour might cause a weird clangd crash when preamble contains some header files that were removed just after the preamble created. Unfortunately it's not so easy to reproduce the crash in the form of a LIT test thus I provided the fix only.

Test Plan:
```
ninja check-clang
```

Reviewed By: aaron.ballman

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