#
5891420e |
| 03-Dec-2022 |
Kazu Hirata <kazu@google.com> |
[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 ...
|
Revision tags: llvmorg-15.0.6 |
|
#
c4436f67 |
| 17-Nov-2022 |
Ben Langmuir <blangmuir@apple.com> |
[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 ...
|
Revision tags: llvmorg-15.0.5, llvmorg-15.0.4 |
|
#
e8541e4b |
| 27-Oct-2022 |
Chuanqi Xu <yedeng.yd@linux.alibaba.com> |
[NFC] [Modules] Rename modules related things in Preprocessor and AffectingModules
Rename module related things according to the consensus in https://discourse.llvm.org/t/rfc-unifying-the-terminolog
[NFC] [Modules] Rename modules related things in Preprocessor and AffectingModules
Rename module related things according to the consensus in https://discourse.llvm.org/t/rfc-unifying-the-terminology-about-modules-in-clang/66054/ to reduce further confusings.
This only renames things I can make sure. It doesn't mean all the names in Preprocessor are correct now.
show more ...
|
#
3a3603ff |
| 25-Oct-2022 |
Fangrui Song <i@maskray.me> |
[clang] Replace BACKEND_PACKAGE_STRING with LLVM_VERSION_STRING
420d7ccbac0f499a6ff9595bdbfa99cd3376df22 introduced BACKEND_PACKAGE_STRING to replace `PACKAGE_VERSION` (llvm/Config/config.h) to supp
[clang] Replace BACKEND_PACKAGE_STRING with LLVM_VERSION_STRING
420d7ccbac0f499a6ff9595bdbfa99cd3376df22 introduced BACKEND_PACKAGE_STRING to replace `PACKAGE_VERSION` (llvm/Config/config.h) to support standalone builds. This is used in the output of `clang -cc1 -v`.
Since llvm-config.h is available for both standalone and non-standalone builds, we can just use `LLVM_VERSION_STRING` from llvm-config.h.
clang/cmake/modules/AddClang.cmake uses `VERSION_STRING "${CLANG_VERSION} (${BACKEND_PACKAGE_STRING})"`. Just simplify it to `"${CLANG_VERSION}"` so that we can remove the CMake variable BACKEND_PACKAGE_STRING.
Reviewed By: tstellar
Differential Revision: https://reviews.llvm.org/D136660
show more ...
|
Revision tags: llvmorg-15.0.3, working |
|
#
5ea78c41 |
| 04-Oct-2022 |
Ben Langmuir <blangmuir@apple.com> |
[clang] Update ModuleMap::getModuleMapFile* to use FileEntryRef
Update SourceManager::ContentCache::OrigEntry to keep the original FileEntryRef, and use that to enable ModuleMap::getModuleMapFile* t
[clang] Update ModuleMap::getModuleMapFile* to use FileEntryRef
Update SourceManager::ContentCache::OrigEntry to keep the original FileEntryRef, and use that to enable ModuleMap::getModuleMapFile* to return the original FileEntryRef. This change should be NFC for most users of SourceManager::ContentCache, but it could affect behaviour for users of getNameAsRequested such as in compileModuleImpl. I have not found a way to detect that difference without additional functional changes, other than incidental cases like changes from / to \ on Windows so there is no new test.
Differential Revision: https://reviews.llvm.org/D135220
show more ...
|
Revision tags: llvmorg-15.0.2, llvmorg-15.0.1 |
|
#
493766e0 |
| 09-Sep-2022 |
Steven Wu <stevenwu@apple.com> |
Frontend: Respect -working-directory when checking if output files can be written
Call `FixupRelativePath` when opening output files to ensure that `-working-directory` is used when checking up fron
Frontend: Respect -working-directory when checking if output files can be written
Call `FixupRelativePath` when opening output files to ensure that `-working-directory` is used when checking up front for write failures, not just when finalizing the files at the end. This also moves the temporary file into the same directory as the output file.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D95497
show more ...
|
Revision tags: llvmorg-15.0.0 |
|
#
82e893c4 |
| 26-Aug-2022 |
Abraham Corea Diaz <abrahamcd@google.com> |
[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 ...
|
Revision tags: llvmorg-15.0.0-rc3 |
|
#
94e64df5 |
| 16-Aug-2022 |
Jan Svoboda <jan_svoboda@apple.com> |
[clang][modules] Consider M affecting after mapping M.Private to M_Private
When Clang encounters `@import M.Private` during implicit build, it precompiles module `M` and looks through its submodules
[clang][modules] Consider M affecting after mapping M.Private to M_Private
When Clang encounters `@import M.Private` during implicit build, it precompiles module `M` and looks through its submodules. If the `Private` submodule is not found, Clang assumes `@import M_Private`. In the dependency scanner, we don't capture the dependency on `M`, since it's not imported. It's an affecting module, though: compilation of the import statement will fail when implicit modules are disabled and `M` is not precompiled and explicitly provided. This patch fixes that.
Depends on D132430.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D132502
show more ...
|
#
002bfdd6 |
| 24-Aug-2022 |
Jan Svoboda <jan_svoboda@apple.com> |
[clang][modules] Track affecting modules
When compiling a module, its semantics and Clang's behavior are affected by other modules. These modules are typically the **imported** ones. However, during
[clang][modules] Track affecting modules
When compiling a module, its semantics and Clang's behavior are affected by other modules. These modules are typically the **imported** ones. However, during implicit build, some modules end up being compiled and read without being actually imported. This patch starts tracking such modules and serializing them into `.pcm` files. This enables the dependency scanner to construct explicit compilations that mimic implicit build.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D132430
show more ...
|
#
3708a148 |
| 22-Aug-2022 |
Ben Langmuir <blangmuir@apple.com> |
[clang] Pull some utility functions into CompilerInvocation NFC
Move copying compiler arguments to a vector<string> and modifying common module-related options into CompilerInvocation in preparation
[clang] Pull some utility functions into CompilerInvocation NFC
Move copying compiler arguments to a vector<string> and modifying common module-related options into CompilerInvocation in preparation for using some of them in more places and to avoid duplicating this code accidentally in the future.
Differential Revision: https://reviews.llvm.org/D132419
show more ...
|
Revision tags: llvmorg-15.0.0-rc2 |
|
#
3f18f7c0 |
| 08-Aug-2022 |
Fangrui Song <i@maskray.me> |
[clang] LLVM_FALLTHROUGH => [[fallthrough]]. NFC
With C++17 there is no Clang pedantic warning or MSVC C5051.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D131346
|
#
fb89cc0d |
| 02-Aug-2022 |
Ben Langmuir <blangmuir@apple.com> |
[clang][modules] Don't depend on sharing FileManager during module build
Sharing the FileManager between the importer and the module build should only be an optimization. Add a cc1 option -fno-modul
[clang][modules] Don't depend on sharing FileManager during module build
Sharing the FileManager between the importer and the module build should only be an optimization. Add a cc1 option -fno-modules-share-filemanager to allow us to test this. Fix the path to modulemap files, which previously depended on the shared FileManager when using path mapped to an external file in a VFS.
Differential Revision: https://reviews.llvm.org/D131076
show more ...
|
Revision tags: llvmorg-15.0.0-rc1, llvmorg-16-init |
|
#
cb2c8f69 |
| 14-Jul-2022 |
Kazu Hirata <kazu@google.com> |
[clang] Use value instead of getValue (NFC)
|
#
67a84ec8 |
| 07-Jul-2022 |
Ben Langmuir <blangmuir@apple.com> |
[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 ...
|
#
3b7c3a65 |
| 25-Jun-2022 |
Kazu Hirata <kazu@google.com> |
Revert "Don't use Optional::hasValue (NFC)"
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
|
#
aa8feeef |
| 25-Jun-2022 |
Kazu Hirata <kazu@google.com> |
Don't use Optional::hasValue (NFC)
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2 |
|
#
706e89db |
| 20-Apr-2022 |
Serge Pavlov <sepavloff@gmail.com> |
Fix interaction of pragma FENV_ACCESS with other pragmas
Previously `#pragma STDC FENV_ACCESS ON` always set dynamic rounding mode and strict exception handling. It is not correct in the presence of
Fix interaction of pragma FENV_ACCESS with other pragmas
Previously `#pragma STDC FENV_ACCESS ON` always set dynamic rounding mode and strict exception handling. It is not correct in the presence of other pragmas that also modify rounding mode and exception handling. For example, the effect of previous pragma FENV_ROUND could be cancelled, which is not conformant with the C standard. Also `#pragma STDC FENV_ACCESS OFF` turned off only FEnvAccess flag, leaving rounding mode and exception handling unchanged, which is incorrect in general case.
Concrete rounding and exception mode depend on a combination of several factors like various pragmas and command-line options. During the review of this patch an idea was proposed that the semantic actions associated with such pragmas should only set appropriate flags. Actual rounding mode and exception handling should be calculated taking into account the state of all relevant options. In such implementation the pragma FENV_ACCESS should not override properties set by other pragmas but should set them if such setting is absent.
To implement this approach the following main changes are made:
- Field `FPRoundingMode` is removed from `LangOptions`. Actually there are no options that set it to arbitrary rounding mode, the choice was only `dynamic` or `tonearest`. Instead, a new boolean flag `RoundingMath` is added, with the same meaning as the corresponding command-line option.
- Type `FPExceptionModeKind` now has possible value `FPE_Default`. It does not represent any particular exception mode but indicates that such mode was not set and default value should be used. It allows to distinguish the case:
{ #pragma STDC FENV_ACCESS ON ... }
where the pragma must set FPE_Strict, from the case:
{ #pragma clang fp exceptions(ignore) #pragma STDC FENV_ACCESS ON ... }
where exception mode should remain `FPE_Ignore`.
- Class `FPOptions` has now methods `getRoundingMode` and `getExceptionMode`, which calculates the respective properties from other specified FP properties.
- Class `LangOptions` has now methods `getDefaultRoundingMode` and `getDefaultExceptionMode`, which calculates default modes from the specified options and should be used instead of `getRoundingMode` and `getFPExceptionMode` of the same class.
Differential Revision: https://reviews.llvm.org/D126364
show more ...
|
#
d3d3e252 |
| 27-May-2022 |
Yuki Okushi <jtitor@2k36.org> |
[CompilerInstance] Fix weird condition on `createCodeCompletionConsumer`
Fixes llvm#53545
Differential Revision: https://reviews.llvm.org/D126524
|
#
99b4874a |
| 15-Apr-2022 |
Jan Svoboda <jan_svoboda@apple.com> |
[clang] NFCI: Use DirectoryEntryRef in collectIncludePCH
This patch removes use of the deprecated `DirectoryEntry::getName()` from `collectIncludePCH` by using `{File,Directory}EntryRef` instead.
R
[clang] NFCI: Use DirectoryEntryRef in collectIncludePCH
This patch removes use of the deprecated `DirectoryEntry::getName()` from `collectIncludePCH` by using `{File,Directory}EntryRef` instead.
Reviewed By: bnbarham
Differential Revision: https://reviews.llvm.org/D123769
show more ...
|
Revision tags: llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init |
|
#
76cb4cd0 |
| 26-Jan-2022 |
Jan Svoboda <jan_svoboda@apple.com> |
[clang] Fix serialized diagnostics edge-cases
The Clang frontend sometimes fails on the following assertion when launched with `-serialize-diagnostic-file <x>`:
``` Assertion failed: (BlockScope.em
[clang] Fix serialized diagnostics edge-cases
The Clang frontend sometimes fails on the following assertion when launched with `-serialize-diagnostic-file <x>`:
``` Assertion failed: (BlockScope.empty() && CurAbbrevs.empty() && "Block imbalance"), function ~BitstreamWriter, file BitstreamWriter.h, line 125. ```
This was first noticed when passing an unknown command-line argument to `-cc1`.
It turns out the `DiagnosticConsumer::finish()` function should be called as soon as processing of all source files ends, but there are some code paths where that doesn't happen:
1. when command line parsing fails in `cc1_main()`, 2. when `!Act.PrepareToExecute(*this)` or `!createTarget()` evaluate to `true` in `CompilerInstance::ExecuteAction` and the function returns early.
This patch ensures `finish()` is called in all those code paths.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D118150
show more ...
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
#
40446663 |
| 09-Jan-2022 |
Kazu Hirata <kazu@google.com> |
[clang] Use true/false instead of 1/0 (NFC)
Identified with modernize-use-bool-literals.
|
#
76f0f1cc |
| 25-Dec-2021 |
Kazu Hirata <kazu@google.com> |
Use {DenseSet,SetVector,SmallPtrSet}::contains (NFC)
|
Revision tags: llvmorg-13.0.1-rc1 |
|
#
ab6ef587 |
| 12-Nov-2021 |
Jan Svoboda <jan_svoboda@apple.com> |
[clang] NFC: Format a loop in CompilerInstance
This code will be moved to a separate function in a future patch. Reformatting now to prevent a bunch of clang-format complains on Phabricator.
|
#
c57ca335 |
| 12-Nov-2021 |
Jan Svoboda <jan_svoboda@apple.com> |
[clang] NFC: Use range-based for loop
|
#
269baa7b |
| 12-Nov-2021 |
Jan Svoboda <jan_svoboda@apple.com> |
[clang] NFC: Remove benign condition
|