aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/FrontendAction.cpp
AgeCommit message (Collapse)AuthorFilesLines
11 days[clang][modules] Serialize `CodeGenOptions` (#146422)Jan Svoboda1-2/+3
Some `LangOptions` duplicate their `CodeGenOptions` counterparts. My understanding is that this was done solely because some infrastructure (like preprocessor initialization, serialization, module compatibility checks, etc.) were only possible/convenient for `LangOptions`. This PR implements the missing support for `CodeGenOptions`, which makes it possible to remove some duplicate `LangOptions` fields and simplify the logic. Motivated by https://github.com/llvm/llvm-project/pull/146342.
2025-07-04[clang-tidy] EndSourceFile() for preprocessor before diagnostic client (#145784)Dave Bartolomeo1-3/+5
The comment for `DiagnosticConsumer::BeginSourceFile()` states that "diagnostics with source range information are required to only be emitted in between BeginSourceFile() and EndSourceFile().". While working on some upcoming changes to the static analyzer, we hit some crashes when diagnostics were reported from the `EndOfMainFile` callback in the preprocessor. This turned out to be because `FrontEndAction::EndSourceFile()` notifies the diagnostic clients of the end of the source file before it notifies the preprocessor. Thus, the diagnostics from the preprocessor callback are reported when the diagnostic client is no longer expecting any diagnostics. The fix is to swap the order of the `EndSourceFile()` calls so that the preprocessor is notified first. I've added asserts to the `ClangTidyDiagnosticConsumer` to catch unexpected diagnostics outside of a source file. Before swapping the order of the calls as described above, this causes several failures in the clang-tidy regression tests. With the swap, there are no failures in `check-all`. rdar://141230583
2025-06-05[Clang][NFC] Use move in std::vector local in HandleTranslationUnit (#142851)Shafik Yaghmour1-1/+1
Static analysis flagged this since we could move MergedRanges since it is a std::vector, a local and unused after that line. So there is a potential saving.
2025-05-22Reapply "[clang] Remove intrusive reference count from `DiagnosticOptions` ↵Jan Svoboda1-6/+6
(#139584)" This reverts commit e2a885537f11f8d9ced1c80c2c90069ab5adeb1d. Build failures were fixed right away and reverting the original commit without the fixes breaks the build again.
2025-05-22Revert "[clang] Remove intrusive reference count from `DiagnosticOptions` ↵Kazu Hirata1-6/+6
(#139584)" This reverts commit 9e306ad4600c4d3392c194a8be88919ee758425c. Multiple builtbot failures have been reported: https://github.com/llvm/llvm-project/pull/139584
2025-05-22[clang] Remove intrusive reference count from `DiagnosticOptions` (#139584)Jan Svoboda1-6/+6
The `DiagnosticOptions` class is currently intrusively reference-counted, which makes reasoning about its lifetime very difficult in some cases. For example, `CompilerInvocation` owns the `DiagnosticOptions` instance (wrapped in `llvm::IntrusiveRefCntPtr`) and only exposes an accessor returning `DiagnosticOptions &`. One would think this gives `CompilerInvocation` exclusive ownership of the object, but that's not the case: ```c++ void shareOwnership(CompilerInvocation &CI) { llvm::IntrusiveRefCntPtr<DiagnosticOptions> CoOwner = &CI.getDiagnosticOptions(); // ... } ``` This is a perfectly valid pattern that is being actually used in the codebase. I would like to ensure the ownership of `DiagnosticOptions` by `CompilerInvocation` is guaranteed to be exclusive. This can be leveraged for a copy-on-write optimization later on. This PR changes usages of `DiagnosticOptions` across `clang`, `clang-tools-extra` and `lldb` to not be intrusively reference-counted.
2025-05-11[clang] Use std::tie to implement operator< (NFC) (#139438)Kazu Hirata1-5/+1
2025-05-06[clang][modules] Lazily load by name lookups in module maps (#132853)Michael Spencer1-4/+4
Instead of eagerly populating the `clang::ModuleMap` when looking up a module by name, this patch changes `HeaderSearch` to only load the modules that are actually used. This introduces `ModuleMap::findOrLoadModule` which will load modules from parsed but not loaded module maps. This cannot be used anywhere that the module loading code calls into as it can create infinite recursion. This currently just reparses module maps when looking up a module by header. This is fine as redeclarations are allowed from the same file, but future patches will also make looking up a module by header lazy. This patch changes the shadow.m test to use explicitly built modules and `#import`. This test and the shadow feature are very brittle and do not work in general. The test relied on pcm files being left behind by prior failing clang invocations that were then reused by the last invocation. If you clean the cache then the last invocation will always fail. This is because the input module map and the `-fmodule-map-file=` module map are parsed in the same module scope, and `-fmodule-map-file=` is forwarded to implicit module builds. That means you are guaranteed to hit a module redeclaration error if the TU actually imports the module it is trying to shadow. This patch changes when we load A2's module map to after the `A` module has been loaded, which sets the `IsFromModuleFile` bit on `A`. This means that A2's `A` is skipped entirely instead of creating a shadow module, and we get textual inclusion. It is possible to construct a case where this would happen before this patch too. An upcoming patch in this series will rework shadowing to work in the general case, but that's only possible once header -> module lookup is lazy too.
2025-04-29[clang] Hide the `LangOptions` pointer from `CompilerInvocation` (#137675)Jan Svoboda1-1/+1
This PR makes `CompilerInvocation` the sole owner of the `LangOptions` instance.
2025-04-25[clang] Do not share ownership of `HeaderSearchOptions` (#132984)Jan Svoboda1-4/+2
This PR makes it so that `CompilerInvocation` is the sole owner of the `HeaderSearchOptions` instance.
2025-04-17Mark the file opened by DeserializedDeclsSourceRangePrinter as a text file ↵Zibi Sarbinowski1-1/+1
(#135842) This PR will fix the following lit failure seeing on z/OS and most likely on Windows: `FAIL: Clang :: Frontend/dump-minimization-hints.cpp` Without `OF_TextWithCRLF` flag, a file is treated as binary and is read improperly, at least on z/OS.
2025-04-11Implement `-dump-minimization-hints` flag. (#133910)Viktoriia Bakalova1-5/+206
This PR implements a CC1 flag `-dump-minimization-hints`. The flag allows to specify a file path to dump ranges of deserialized declarations in `ASTReader`. Example usage: ``` clang -Xclang=-dump-minimization-hints=/tmp/decls -c file.cc -o file.o ``` Example output: ``` // /tmp/decls { "required_ranges": [ { "file": "foo.h", "range": [ { "from": { "line": 26, "column": 1 }, "to": { "line": 27, "column": 77 } } ] }, { "file": "bar.h", "range": [ { "from": { "line": 30, "column": 1 }, "to": { "line": 35, "column": 1 } }, { "from": { "line": 92, "column": 1 }, "to": { "line": 95, "column": 1 } } ] } ] } ``` Specifying the flag creates an instance of `DeserializedDeclsSourceRangePrinter`, which dumps ranges of deserialized declarations to aid debugging and bug minimization (we use is as input to [C-Vise](https://github.com/emaxx-google/cvise/tree/multifile-hints). Required ranges are computed from source ranges of Decls. `TranslationUnitDecl`, `LinkageSpecDecl` and `NamespaceDecl` are ignored for the sake of this PR. Technical details: * `DeserializedDeclsSourceRangePrinter` implements `ASTConsumer` and `ASTDeserializationListener`, so that an object of `DeserializedDeclsSourceRangePrinter` registers as its own listener. * `ASTDeserializationListener` interface provides the `DeclRead` callback that we use to collect the deserialized Decls. Printing or otherwise processing them as this point is dangerous, since that could trigger additional deserialization and crash compilation. * The collected Decls are processed in `HandleTranslationUnit` method of `ASTConsumer`. This is a safe point, since we know that by this point all the Decls needed by the compiler frontend have been deserialized. * In case our processing causes further deserialization, `DeclRead` from the listener might be called again. However, at that point we don't accept any more Decls for processing.
2025-03-29[Clang] Check PP presence when printing stats (#131608)Qiu Chaofan1-4/+8
Front-end option `-print-stats` can be used to print statistics around the compilation process. But clang with this options will crash when input is IR file. This patch fixes the crash by checking preprocessor presence before invoking it.
2025-03-28[clang] Implement some missing interfaces for ↵Haojian Wu1-46/+0
DelegatingDeserializationListener (#133424) Split from the https://github.com/llvm/llvm-project/pull/133395 per the review comment. This patch also moves the `DelegatingDeserializationListener` close to `ASTDeserializationListener`.
2025-01-12-ftime-report: Move FrontendTimer closer to TimeTraceScopeFangrui Song1-6/+1
... to improve consistency and make "Clang time report" cover `FrontendAction::BeginSourceFile` and `FrontendAction::EndSourceFile`.
2024-10-28[clang][modules] Preserve the module map that allowed inferring (#113389)Jan Svoboda1-1/+0
With inferred modules, the dependency scanner takes care to replace the fake "__inferred_module.map" path with the file that allowed the module to be inferred. However, this only worked when such a module was imported directly in the TU. Whenever such module got loaded transitively, the scanner would fail to perform the replacement. This is caused by the fact that PCM files are lossy and drop this information. This patch makes sure that PCMs include this file for each submodule (in the `SUBMODULE_DEFINITION` record), fixes one existing test with an incorrect assertion, and does a little drive-by refactoring of `ModuleMap`.
2024-10-25[clang][modules] Shrink the size of `Module::Headers` (#113395)Jan Svoboda1-1/+1
This patch shrinks the size of the `Module` class from 2112B to 1624B. I wasn't able to get a good data on the actual impact on memory usage, but given my `clang-scan-deps` workload at hand (with tens of thousands of instances), I think there should be some win here. This also speeds up my benchmark by under 0.1%.
2024-09-23[Frontend] Teach LoadFromASTFile to take FileName by StringRef (NFC) (#109583)Kazu Hirata1-5/+5
Without this patch, several callers of LoadFromASTFile construct an instance of std::string to be passed as FileName, only to be converted back to StringRef when LoadFromASTFile calls ReadAST. This patch changes the type of FileName to StringRef and updates the callers.
2024-05-13[NFC] [Serialization] Merge IdentID with IdentifierIDChuanqi Xu1-1/+1
In ASTBitCodes.h, there are two type alias for the ID type of Identifiers with the same underlying type. It is confusing. This patch tries to merge the `IdentID` to `IdentifierID` to erase such confusion.
2024-04-25[Clang] Diagnose apply AST consume actions on LLVM IR (#88602)yronglin1-2/+5
Fixes https://github.com/llvm/llvm-project/issues/88522 This PR introduce a new diagnostic to report apply AST consume actions on LLVM IR. --------- Signed-off-by: yronglin <yronglin777@gmail.com>
2024-04-25[NFC] [Serialization] Avoid using DeclID directly as much as possibleChuanqi Xu1-3/+3
This patch tries to remove all the direct use of DeclID except the real low level reading and writing. All the use of DeclID is converted to the use of LocalDeclID or GlobalDeclID. This is helpful to increase the readability and type safety.
2024-04-25Revert "[NFC] [Serialization] Avoid using DeclID directly as much as possible"Chuanqi Xu1-3/+3
This reverts commit 42070a5c092ed420bf92ebf38229c594885e94c7. I forgot to touch lldb.
2024-04-25[NFC] [Serialization] Avoid using DeclID directly as much as possibleChuanqi Xu1-3/+3
This patch tries to remove all the direct use of DeclID except the real low level reading and writing. All the use of DeclID is converted to the use of LocalDeclID or GlobalDeclID. This is helpful to increase the readability and type safety.
2024-04-25[NFC] Move DeclID from serialization/ASTBitCodes.h to AST/DeclID.h (#89873)Chuanqi Xu1-3/+3
Previously, the DeclID is defined in serialization/ASTBitCodes.h under clang::serialization namespace. However, actually the DeclID is not purely used in serialization part. The DeclID is already widely used in AST and all around the clang project via classes like `LazyPtrDecl` or calling `ExternalASTSource::getExernalDecl()`. All such uses are via the raw underlying type of `DeclID` as `uint32_t`. This is not pretty good. This patch moves the DeclID class family to a new header `AST/DeclID.h` so that the whole project can use the wrapped class `DeclID`, `GlobalDeclID` and `LocalDeclID` instead of the raw underlying type. This can improve the readability and the type safety.
2024-03-28[clang][modules] Avoid calling expensive `SourceManager::translateFile()` ↵Jan Svoboda1-2/+8
(#86216) The `ASTWriter` algorithm for computing affecting module maps uses `SourceManager::translateFile()` to get a `FileID` from a `FileEntry`. This is slow (O(n)) since the function performs a linear walk over `SLocEntries` until it finds one with a matching `FileEntry`. This patch removes this use of `SourceManager::translateFile()` by tracking `FileID` instead of `FileEntry` in couple of places in `ModuleMap`, giving `ASTWriter` the desired `FileID` directly. There are no changes required for clients that still want a `FileEntry` from `ModuleMap`: the existing APIs internally use `SourceManager` to perform the reverse `FileID` to `FileEntry` conversion in O(1).
2024-02-23[C++20] [Modules] Allow to compile a pcm with and without -fPICChuanqi Xu1-1/+1
seperately We can compile a module unit in 2 phase compilaton: ``` clang++ -std=c++20 a.cppm --precompile -o a.pcm clang++ -std=c++20 a.pcm -c -o a.o ``` And it is a general requirement that we need to compile a translation unit with and without -fPIC for static and shared libraries. But for C++20 modules with 2 phase compilation, it may be waste of time to compile them 2 times completely. It may be fine to generate one BMI and compile it with and without -fPIC seperately. e.g., ``` clang++ -std=c++20 a.cppm --precompile -o a.pcm clang++ -std=c++20 a.pcm -c -o a.o clang++ -std=c++20 a.pcm -c -fPIC -o a-PIC.o ``` Then we can save the time to parse a.cppm repeatedly.
2023-11-28[clang] Remove unused argument. NFC. (#73594)Juergen Ributzka1-3/+2
2023-10-08[clang][Modules] `checkModuleIsAvailable` should use a const & parameter ↵David Stone1-2/+2
instead of pointer (#67902) The `Module` parameter to `checkModuleIsAvailable` is currently passed by pointer to non-const. However, it requires only const access and it cannot be null. Change this to be a reference to const instead. This then makes it obvious that it is an input-only parameter, so move it to be before the in-out parameter for diagnostics.
2023-09-29[clang] NFCI: Use `FileEntryRef` in `ASTReader::GetHeaderFileInfo()`Jan Svoboda1-2/+2
This is the `ASTReader` counterpart to PR #67383.
2023-09-28[clang] NFCI: Use `FileEntryRef` in `SourceManager::setFileIsTransient()`Jan Svoboda1-1/+1
2023-09-13[clang] NFCI: Use `FileEntryRef` in `ModuleMap::InferredModuleAllowedBy`Jan Svoboda1-4/+4
2023-09-08Reapply "[clang] NFCI: Adopt `SourceManager::getFileEntryRefForID()`"Jan Svoboda1-2/+2
This reapplies ddbcc10b9e26b18f6a70e23d0611b9da75ffa52f, except for a tiny part that was reverted separately: 65331da0032ab4253a4bc0ddcb2da67664bd86a9. That will be reapplied later on, since it turned out to be more involved. This commit is enabled by 5523fefb01c282c4cbcaf6314a9aaf658c6c145f and f0f548a65a215c450d956dbcedb03656449705b9, specifically the part that makes 'clang-tidy/checkers/misc/header-include-cycle.cpp' separator agnostic.
2023-09-07[NFC] [C++20] [Modules] Refactor the warning to '-fmodule-file=<BMIPath>' ↵Chuanqi Xu1-2/+8
for C++20 modules Previous implementation of the warning to use `-fmodule-file=<BMIPath>` for C++20 Modules is not straightforward and it is problematic in case we read the BMIPath by writing tools based clang components. This patch refactors it with a simple and direct style.
2023-09-06Revert "[clang] NFCI: Adopt `SourceManager::getFileEntryRefForID()`"Jan Svoboda1-2/+2
This reverts commit ddbcc10b9e26b18f6a70e23d0611b9da75ffa52f. The 'clang-tidy/checkers/misc/header-include-cycle.cpp' test started failing on Windows: https://lab.llvm.org/buildbot/#/builders/216/builds/26855.
2023-09-06[clang] NFCI: Adopt `SourceManager::getFileEntryRefForID()`Jan Svoboda1-2/+2
This commit replaces some calls to the deprecated `FileEntry::getName()` with `FileEntryRef::getName()` by swapping current usages of `SourceManager::getFileEntryForID()` with `SourceManager::getFileEntryRefForID()`. This lowers the number of usages of the deprecated `FileEntry::getName()` from 95 to 50.
2023-09-02[clang][clangd] Ensure the stack bottom before building ASTYounan Zhang1-0/+5
`clang::runWithSufficientStackSpace` requires the address of the initial stack bottom to prevent potential stack overflows. In addition, add a fallback to ASTFrontendAction in case any client forgets to call it when not through CompilerInstance::ExecuteAction, which is rare. Fixes https://github.com/clangd/clangd/issues/1745. Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D158967
2023-07-28[NFC][clang] Fix static analyzer concernsPodchishchaeva, Mariya1-0/+5
DelegatingDeserializationListener frees resources in the destructor but doesn't have user-written copy c'tor or assignment operator, so copying it using default ones can cause double free. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D156405
2023-06-15[clang][index] NFCI: Make `CXFile` a `FileEntryRef`Jan Svoboda1-3/+1
This patch swaps out the `void *` behind `CXFile` from `FileEntry *` to `FileEntryRef::MapEntry *`. This allows us to remove some deprecated uses of `FileEntry::getName()`. Depends on D151854. Reviewed By: benlangmuir Differential Revision: https://reviews.llvm.org/D151938
2023-05-30[clang][lex] NFCI: Use DirectoryEntryRef in HeaderSearch::LookupFileJan Svoboda1-5/+3
This patch changes the argument type to `HeaderSearch::LookupFile()` from `const DirectoryEntry *` to `DirectoryEntryRef` in order to remove some calls to the deprecated `DirectoryEntry::getName()`. Depends on D127660. Reviewed By: bnbarham, benlangmuir Differential Revision: https://reviews.llvm.org/D127663
2023-05-30[clang][modules] NFCI: Extract optionality out of ↵Jan Svoboda1-8/+10
`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
2023-05-30[clang][lex] NFCI: Use DirectoryEntryRef in Preprocessor::MainFileDirJan Svoboda1-1/+1
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
2023-05-30[clang][lex] NFCI: Use DirectoryEntryRef in ModuleMap::inferFrameworkModule()Jan Svoboda1-1/+2
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
2023-05-30[clang][lex] NFCI: Use FileEntryRef in ModuleMap::{load,lookup}ModuleMap()Jan Svoboda1-4/+5
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
2023-05-26[clang][modules] NFCI: Distinguish as-written and effective umbrella directoriesJan Svoboda1-3/+4
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
2023-05-23[C++20] [Modules] Don't ignore -fmodule-file when we compile pcm filesChuanqi Xu1-1/+2
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.
2023-04-24[clang] Make access to submodules via `iterator_range`Stoorx1-4/+2
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
2023-02-06[Modules] Recreate file manager for ftime-trace when compiling a moduleChuanqi Xu1-0/+3
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.
2023-01-20[clang][nfc] refactor Module::Header to use OptionalFileEntryRefRichard Howell1-2/+5
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
2022-12-20[Clang] Prepare for llvm::Optional becoming std::optional.Benjamin Kramer1-1/+1
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
2022-12-18Revert "[clang] Convert OptionalFileEntryRefDegradesToFileEntryPtr to ↵Krzysztof Parzyszek1-2/+1
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).