[clang][modules] NFCI: Extract optionality out of `Module::{Header,DirectoryName}`

Most users of `Module::Header` already assume its `Entry` is populated. Enforce this assumption in the type system

[clang][modules] NFCI: Extract optionality out of `Module::{Header,DirectoryName}`

Most users of `Module::Header` already assume its `Entry` is populated. Enforce this assumption in the type system and handle the only case where this is not the case by wrapping the whole struct in `std::optional`. Do the same for `Module::DirectoryName`.

Depends on D151584.

Reviewed By: benlangmuir

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

show more ...

[clang][lex] NFCI: Use DirectoryEntryRef in Preprocessor::MainFileDir

This patch changes the type of `Preprocessor::MainFileDir` from `const DirectoryEntry *` to `Optional<DirectoryEntryRef>` in ord

[clang][lex] NFCI: Use DirectoryEntryRef in Preprocessor::MainFileDir

This patch changes the type of `Preprocessor::MainFileDir` from `const DirectoryEntry *` to `Optional<DirectoryEntryRef>` in order to remove some calls to the deprecated `DirectoryEntry::getName()`.

Depends on D127658.

Reviewed By: bnbarham

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

show more ...

[clang][lex] NFCI: Use DirectoryEntryRef in ModuleMap::inferFrameworkModule()

This patch changes the argument type of `ModuleMap::inferFrameworkModule()` from `const DirectoryEntry *` to `DirectoryE

[clang][lex] NFCI: Use DirectoryEntryRef in ModuleMap::inferFrameworkModule()

This patch changes the argument type of `ModuleMap::inferFrameworkModule()` from `const DirectoryEntry *` to `DirectoryEntryRef` in order to remove the deprecated uses of `DirectoryEntry::getName()`.

Depends on D127647.

Reviewed By: bnbarham

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

show more ...

[clang][lex] NFCI: Use FileEntryRef in ModuleMap::{load,lookup}ModuleMap()

This patch changes the return/argument types of `ModuleMap::{load,lookup}ModuleMap()` from `const FileEntry *` to `FileEntr

[clang][lex] NFCI: Use FileEntryRef in ModuleMap::{load,lookup}ModuleMap()

This patch changes the return/argument types of `ModuleMap::{load,lookup}ModuleMap()` from `const FileEntry *` to `FileEntryRef` in order to remove uses of the deprecated `DirectoryEntry::getName()`.

Reviewed By: bnbarham

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

show more ...

[clang][modules] NFCI: Distinguish as-written and effective umbrella directories

For modules with umbrellas, we track how they were written in the module map. Unfortunately, the getter for the umbre

[clang][modules] NFCI: Distinguish as-written and effective umbrella directories

For modules with umbrellas, we track how they were written in the module map. Unfortunately, the getter for the umbrella directory conflates the "as written" directory and the "effective" directory (either the written one or the parent of the written umbrella header).

This patch makes the distinction between "as written" and "effective" umbrella directories clearer. No functional change intended.

Reviewed By: benlangmuir

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

show more ...

[C++20] [Modules] Don't ignore -fmodule-file when we compile pcm files

Close https://github.com/llvm/llvm-project/issues/62843.

Previously when we compile .pcm files into .o files, the
`-fmodule-fi

[C++20] [Modules] Don't ignore -fmodule-file when we compile pcm files

Close https://github.com/llvm/llvm-project/issues/62843.

Previously when we compile .pcm files into .o files, the
`-fmodule-file=<module-name>=<module-path>` option is ignored. This is
conflicted with our consensus in
https://github.com/llvm/llvm-project/issues/62707.

show more ...

[clang] Make access to submodules via `iterator_range`

In file `clang/lib/Basic/Module.cpp` the `Module` class had `submodule_begin()` and `submodule_end()` functions to retrieve corresponding itera

[clang] Make access to submodules via `iterator_range`

In file `clang/lib/Basic/Module.cpp` the `Module` class had `submodule_begin()` and `submodule_end()` functions to retrieve corresponding iterators for private vector of Modules. This commit removes mentioned functions, and replaces all of theirs usages with `submodules()` function and range-based for-loops.

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

show more ...

[Modules] Recreate file manager for ftime-trace when compiling a module

Close https://github.com/llvm/llvm-project/issues/60544.

The root cause for the issue is that when we compile a module unit,

[Modules] Recreate file manager for ftime-trace when compiling a module

Close https://github.com/llvm/llvm-project/issues/60544.

The root cause for the issue is that when we compile a module unit, the
file manager (and proprocessor and source manager) are owned by AST
instead of the compilaton instance. So the file manager may be invalid
when we want to create a time-report file for -ftime-trace when we are
compiling a module unit.

This patch tries to recreate the file manager for -ftime-trace if we
find the file manager is not valid.

show more ...

[clang][nfc] refactor Module::Header to use OptionalFileEntryRef

Refactor the `Module::Header` class to use an `OptionalFileEntryRef`
instead of a `FileEntry*`. This is preparation for refactoring t

[clang][nfc] refactor Module::Header to use OptionalFileEntryRef

Refactor the `Module::Header` class to use an `OptionalFileEntryRef`
instead of a `FileEntry*`. This is preparation for refactoring the
`TopHeaderNames` to use `FileEntryRef` so that we preserve the
lookup path of the headers when serializing.

This is mostly based on https://reviews.llvm.org/D90497

Reviewed By: jansvoboda11

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

show more ...

[Clang] Prepare for llvm::Optional becoming std::optional.

The needed tweaks are mostly trivial, the one nasty bit is Clang's usage
of OptionalStorage. To keep this working old Optional stays around

[Clang] Prepare for llvm::Optional becoming std::optional.

The needed tweaks are mostly trivial, the one nasty bit is Clang's usage
of OptionalStorage. To keep this working old Optional stays around as
clang::CustomizableOptional, with the default Storage removed.
Optional<File/DirectoryEntryRef> is replaced with a typedef.

I tested this with GCC 7.5, the oldest supported GCC I had around.

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

show more ...

Revert "[clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr to std::optional"

This reverts commit 8f0df9f3bbc6d7f3d5cbfd955c5ee4404c53a75d.

The Optional*RefDegradesTo*EntryPtr types want to

Revert "[clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr to std::optional"

This reverts commit 8f0df9f3bbc6d7f3d5cbfd955c5ee4404c53a75d.

The Optional*RefDegradesTo*EntryPtr types want to keep the same size as
the underlying type, which std::optional doesn't guarantee. For use with
llvm::Optional, they define their own storage class, and there is no way
to do that in std::optional.

On top of that, that commit broke builds with older GCCs, where
std::optional was not trivially copyable (static_assert in the clang
sources was failing).

show more ...

[clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr to std::optional

[clang] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of m

[clang] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[clang] Use InMemoryModuleCache for readASTFileControlBlock NFC

When a pcm has already been loaded from disk, reuse it from the
InMemoryModuleCache in readASTFileControlBlock. This avoids potentiall

[clang] Use InMemoryModuleCache for readASTFileControlBlock NFC

When a pcm has already been loaded from disk, reuse it from the
InMemoryModuleCache in readASTFileControlBlock. This avoids potentially
reading it again.

As noted in the FIXME, ideally we would also add the module to the cache
if it will be used again later, but that could modify its build state
and we do not have enough context currenlty to know if it's correct.

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

show more ...

[clang][deps] Avoid leaking modulemap paths across unrelated imports

Use a FileEntryRef when retrieving modulemap paths in the scanner so
that we use a path compatible with the original module impor

[clang][deps] Avoid leaking modulemap paths across unrelated imports

Use a FileEntryRef when retrieving modulemap paths in the scanner so
that we use a path compatible with the original module import, rather
than a FileEntry which can allow unrelated modules to leak paths into
how we build a module due to FileManager mutating the path.

Note: the current change prevents an "unrelated" path, but does not
change how VFS mapped paths are handled (which would be calling
getNameAsRequested) nor canonicalize the path.

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

show more ...

[clang][deps] Prevent emitting diagnostics outside of source file

The dependency scanner needs to report the module map file describing the module whose implementation is being compiled (see D134222

[clang][deps] Prevent emitting diagnostics outside of source file

The dependency scanner needs to report the module map file describing the module whose implementation is being compiled (see D134222). However, calling `Preprocessor::getCurrentModuleImplementation()` in the scanner might cause a diagnostic during module map parsing and emitting a diagnostic without being "in" a source file is illegal (e.g. in `TextDiagnosticPrinter`). This patch ensures the module map parse is triggered while the compiler is still "in" a source file, avoiding the failure case.

Reviewed By: Bigcheese

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

show more ...

[HLSL] Support PCH for cc1 mode

Add HLSLExternalSemaSource as ExternalSemaSource instead of ASTContext::ExternalSource when PCH is included.

This allows a different external source to be set for th

[HLSL] Support PCH for cc1 mode

Add HLSLExternalSemaSource as ExternalSemaSource instead of ASTContext::ExternalSource when PCH is included.

This allows a different external source to be set for the AST context.

Reviewed By: beanz

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

show more ...

Use llvm::is_contained (NFC)

[clang] Enable output of SARIF diagnostics

Enables Clang to emit diagnostics in SARIF format when
`-fdiagnostics-format=sarif`. Adds a new DiagnosticConsumer named
SARIFDiagnosticPrinter and a new D

[clang] Enable output of SARIF diagnostics

Enables Clang to emit diagnostics in SARIF format when
`-fdiagnostics-format=sarif`. Adds a new DiagnosticConsumer named
SARIFDiagnosticPrinter and a new DiagnosticRenderer named SARIFDiagnostic
to constuct and emit a SARIF object containing the run's basic diagnostic info.

Reviewed By: cjdb, denik, aaron.ballman

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

show more ...

[clang] Require strict matches for defines for PCH in GCC style directories

When clang includes a PCH, it tolerates some amount of differences
between the defines used when creating and when includi

[clang] Require strict matches for defines for PCH in GCC style directories

When clang includes a PCH, it tolerates some amount of differences
between the defines used when creating and when including the PCH
- this seems to be intentionally allowed in
c379c072405f39bca1d3552408fc0427328e8b6d (and later extended in
b63687519610a73dd565be1fec28332211b4df5b).

When using a PCH (or when picking a PCH out of a directory containing
multiple candidates) Clang used to accept the header if there were
defines on the command line when creating the PCH that are missing
when using the PCH, or vice versa, defines only set when using the
PCH.

The only cases where Clang explicitly rejected the use of a PCH
is if there was an explicit conflict between the options, e.g.
-DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO.

The latter commit added a FIXME that we really should check whether
mismatched defines actually were used somewhere in the PCH, so that
the define would affect the outcome. This FIXME has stood unaddressed
since 2012.

This differs from GCC, which rejects PCH files if the defines differ
at all.

When explicitly including a single PCH file, the relaxed policy
of allowing minor differences is harmless for correct use cases
(but may fail to diagnose mismtaches), and potentially allow using
PCHs in wider cases (where the user intentionally know that the
differences in defines are harmless for the PCH).

However, for GCC style PCH directories, with a directory containing
multiple PCH variants and the compiler should pick the correct match
out of them, Clang's relaxed logic was problematic. The directory
could contain two otherwise identical PCHs, but one built with -DFOO
and one without. When attempting to include a PCH and iterating over
the candidates in the directory, Clang would essentially pick the
first one out of the two, even if there existed a better, exact
match in the directory.

Keep the relaxed checking when specificlly including one named
PCH file, but require strict matches when trying to pick the right
candidate out of a GCC style directory with alternatives.

This fixes https://github.com/lhmouse/mcfgthread/issues/63.

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

show more ...

Use the range-based overload of llvm::sort where possible

Reviewed By: MaskRay

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

[clang] Cleanup ASTContext before output files in crash recovery for modules

When we recover from a crash in a module compilation thread, we need to
ensure any output streams owned by the ASTConsume

[clang] Cleanup ASTContext before output files in crash recovery for modules

When we recover from a crash in a module compilation thread, we need to
ensure any output streams owned by the ASTConsumer (e.g. in
RawPCHContainerGenerator) are deleted before we call clearOutputFiles().
This has the same theoretical issues with proxy streams that Duncan
discusses in the commit 2d133867833fe8eb. In practice, this was observed
as a use-after-free crash on a downstream branch that uses such a proxy
stream in this code path. Add an assertion so it won't regress.

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

rdar://96525032

show more ...

[HLSL] Add ExternalSemaSource & vector alias

HLSL vector types are ext_vector types, but they are also exposed via a
template syntax `vector<T, #>`. This is morally equavalent to the code:

```c++
t

[HLSL] Add ExternalSemaSource & vector alias

HLSL vector types are ext_vector types, but they are also exposed via a
template syntax `vector<T, #>`. This is morally equavalent to the code:

```c++
template <typename T, int Size>
using vector = T __attribute__((ext_vector_type(Size)))
```

The problem is that templates aren't supported before HLSL 2021, and
type aliases still aren't supported in HLSL.

To resolve this (and other issues where HLSL can't represent its own
types), we rely on an external AST & Sema source being registered for
HLSL code.

This patch adds the HLSLExternalSemaSource and registers the vector
type alias.

Depends on D127802

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

show more ...

Prefer `getCurrentFileOrBufferName` in `FrontendAction::EndSourceFile`

`getCurrentFile` here causes an assertion on some condition.
`getCurrentFileOrBufferName` is preferrable instead.

llvm#55950

Prefer `getCurrentFileOrBufferName` in `FrontendAction::EndSourceFile`

`getCurrentFile` here causes an assertion on some condition.
`getCurrentFileOrBufferName` is preferrable instead.

llvm#55950

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

show more ...

Revert "wip"

This reverts commit 0dd243fa8a4ec98d6cabbad16e6b485a093c6dea.

I accidentally pushed this! Oops!