diff options
| author | Duncan P. N. Exon Smith <dexonsmith@apple.com> | 2021-04-30 15:23:47 -0700 |
|---|---|---|
| committer | Duncan P. N. Exon Smith <dexonsmith@apple.com> | 2021-05-13 10:39:40 -0700 |
| commit | 7c57a9bd7d4c976b7a824472c427433359200e02 (patch) | |
| tree | 60aac6b379191d934ad7381d117f4d7d92a9ea15 /llvm/lib/Support/TargetParser.cpp | |
| parent | 16d03818412415c56efcd482d18c0cbdf712524c (diff) | |
| download | llvm-7c57a9bd7d4c976b7a824472c427433359200e02.zip llvm-7c57a9bd7d4c976b7a824472c427433359200e02.tar.gz llvm-7c57a9bd7d4c976b7a824472c427433359200e02.tar.bz2 | |
Modules: Simplify how DisableGeneratingGlobalModuleIndex is set, likely NFC
DisableGeneratingGlobalModuleIndex was being set by
CompilerInstance::findOrCompileModuleAndReadAST most of (but not all of)
the times it returned `nullptr` as a "normal" failure. Pull that up to
the caller, CompilerInstance::loadModule, to simplify the code. This
resolves a number of FIXMEs added during the refactoring in
5cca622310c10fdf6f921b6cce26f91d9f14c762.
The extra cases where this is set are all some version of a fatal error,
and the only client of the field, shouldBuildGlobalModuleIndex, seems
to be unreachable in that case. Even if there is some corner case where
this has an effect, it seems like the right/consistent behaviour.
Differential Revision: https://reviews.llvm.org/D101672
Diffstat (limited to 'llvm/lib/Support/TargetParser.cpp')
0 files changed, 0 insertions, 0 deletions