History log of /llvm-project/clang/lib/Frontend/CompilerInstance.cpp (Results 51 – 75 of 684)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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


12345678910>>...28