History log of /llvm-project/clang/lib/Frontend/FrontendActions.cpp (Results 1 – 25 of 342)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# 28ad8978 23-Jan-2025 Matheus Izvekov <mizvekov@gmail.com>

Reland: [clang] unified CWG2398 and P0522 changes; finishes implementation of P3310 (#124137)

This patch relands the following PRs:
* #111711
* #107350
* #111457

All of these patches were reve

Reland: [clang] unified CWG2398 and P0522 changes; finishes implementation of P3310 (#124137)

This patch relands the following PRs:
* #111711
* #107350
* #111457

All of these patches were reverted due to an issue reported in
https://github.com/llvm/llvm-project/pull/111711#issuecomment-2406491485,
due to interdependencies.

---
[clang] Finish implementation of P0522

This finishes the clang implementation of P0522, getting rid
of the fallback to the old, pre-P0522 rules.

Before this patch, when partial ordering template template parameters,
we would perform, in order:
* If the old rules would match, we would accept it. Otherwise, don't
generate diagnostics yet.
* If the new rules would match, just accept it. Otherwise, don't
generate any diagnostics yet again.
* Apply the old rules again, this time with diagnostics.

This situation was far from ideal, as we would sometimes:
* Accept some things we shouldn't.
* Reject some things we shouldn't.
* Only diagnose rejection in terms of the old rules.

With this patch, we apply the P0522 rules throughout.

This needed to extend template argument deduction in order
to accept the historial rule for TTP matching pack parameter to non-pack
arguments.
This change also makes us accept some combinations of historical and P0522
allowances we wouldn't before.

It also fixes a bunch of bugs that were documented in the test suite,
which I am not sure there are issues already created for them.

This causes a lot of changes to the way these failures are diagnosed,
with related test suite churn.

The problem here is that the old rules were very simple and
non-recursive, making it easy to provide customized diagnostics,
and to keep them consistent with each other.

The new rules are a lot more complex and rely on template argument
deduction, substitutions, and they are recursive.

The approach taken here is to mostly rely on existing diagnostics,
and create a new instantiation context that keeps track of this context.

So for example when a substitution failure occurs, we use the error
produced there unmodified, and just attach notes to it explaining
that it occurred in the context of partial ordering this template
argument against that template parameter.

This diverges from the old diagnostics, which would lead with an
error pointing to the template argument, explain the problem
in subsequent notes, and produce a final note pointing to the parameter.

---
[clang] CWG2398: improve overload resolution backwards compat

With this change, we discriminate if the primary template and which partial
specializations would have participated in overload resolution prior to
P0522 changes.

We collect those in an initial set. If this set is not empty, or the
primary template would have matched, we proceed with this set as the
candidates for overload resolution.

Otherwise, we build a new overload set with everything else, and proceed
as usual.

---
[clang] Implement TTP 'reversed' pack matching for deduced function template calls.

Clang previously missed implementing P0522 pack matching
for deduced function template calls.

show more ...


Revision tags: llvmorg-19.1.7
# c1ecc0d1 03-Jan-2025 Alejandro Álvarez Ayllón <alejandro.alvarez@sonarsource.com>

[clang] Allow generating module interfaces with parsing errors (#121485)

Fixes a regression introduced in commit
da00c60dae0040185dc45039c4397f6e746548e9

This functionality was originally added

[clang] Allow generating module interfaces with parsing errors (#121485)

Fixes a regression introduced in commit
da00c60dae0040185dc45039c4397f6e746548e9

This functionality was originally added in commit
5834996fefc937d6211dc8c8a5b200068753391a

Co-authored-by: Tomasz Kaminski <tomasz.kaminski@sonarsource.com>

show more ...


Revision tags: llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3
# af7c58b7 28-Oct-2024 Aaron Ballman <aaron@aaronballman.com>

Remove support for RenderScript (#112916)

See
https://discourse.llvm.org/t/rfc-deprecate-and-eventually-remove-renderscript-support/81284
for the RFC


Revision tags: llvmorg-19.1.2
# efcfa6e7 11-Oct-2024 Mikhail Goncharov <goncharov.mikhail@gmail.com>

Revert "Reland: [clang] Finish implementation of P0522 (#111711)"

See discussion in https://github.com/llvm/llvm-project/pull/111711

This reverts commit 6213aa5e58a7d32bdc82dd40322fb1bab83c4783.


# 6213aa5e 10-Oct-2024 Matheus Izvekov <mizvekov@gmail.com>

Reland: [clang] Finish implementation of P0522 (#111711)

This finishes the clang implementation of P0522, getting rid of the
fallback to the old, pre-P0522 rules.

Before this patch, when partial

Reland: [clang] Finish implementation of P0522 (#111711)

This finishes the clang implementation of P0522, getting rid of the
fallback to the old, pre-P0522 rules.

Before this patch, when partial ordering template template parameters,
we would perform, in order:
* If the old rules would match, we would accept it. Otherwise, don't
generate diagnostics yet.
* If the new rules would match, just accept it. Otherwise, don't
generate any diagnostics yet again.
* Apply the old rules again, this time with diagnostics.

This situation was far from ideal, as we would sometimes:
* Accept some things we shouldn't.
* Reject some things we shouldn't.
* Only diagnose rejection in terms of the old rules.

With this patch, we apply the P0522 rules throughout.

This needed to extend template argument deduction in order to accept the
historial rule for TTP matching pack parameter to non-pack arguments.
This change also makes us accept some combinations of historical and
P0522 allowances we wouldn't before.

It also fixes a bunch of bugs that were documented in the test suite,
which I am not sure there are issues already created for them.

This causes a lot of changes to the way these failures are diagnosed,
with related test suite churn.

The problem here is that the old rules were very simple and
non-recursive, making it easy to provide customized diagnostics, and to
keep them consistent with each other.

The new rules are a lot more complex and rely on template argument
deduction, substitutions, and they are recursive.

The approach taken here is to mostly rely on existing diagnostics, and
create a new instantiation context that keeps track of this context.

So for example when a substitution failure occurs, we use the error
produced there unmodified, and just attach notes to it explaining that
it occurred in the context of partial ordering this template argument
against that template parameter.

This diverges from the old diagnostics, which would lead with an error
pointing to the template argument, explain the problem in subsequent
notes, and produce a final note pointing to the parameter.

show more ...


# ada6372e 07-Oct-2024 Hans Wennborg <hans@chromium.org>

Revert "[clang] Finish implementation of P0522 (#96023)"

This caused Clang to reject valid code, see discussion on the PR
https://github.com/llvm/llvm-project/pull/96023#issuecomment-2393228464
and

Revert "[clang] Finish implementation of P0522 (#96023)"

This caused Clang to reject valid code, see discussion on the PR
https://github.com/llvm/llvm-project/pull/96023#issuecomment-2393228464
and https://github.com/llvm/llvm-project/issues/111363

This reverts commit 6afe56732a172d3f2cbd0330b1fcb34bbfd002a9 and
follow-up commit 9abb97f9663a27fe5b8e346ed557b3435aa9ec2f.

show more ...


# 6afe5673 01-Oct-2024 Matheus Izvekov <mizvekov@gmail.com>

[clang] Finish implementation of P0522 (#96023)

This finishes the clang implementation of P0522, getting rid of the
fallback to the old, pre-P0522 rules.

Before this patch, when partial ordering

[clang] Finish implementation of P0522 (#96023)

This finishes the clang implementation of P0522, getting rid of the
fallback to the old, pre-P0522 rules.

Before this patch, when partial ordering template template parameters,
we would perform, in order:
* If the old rules would match, we would accept it. Otherwise, don't
generate diagnostics yet.
* If the new rules would match, just accept it. Otherwise, don't
generate any diagnostics yet again.
* Apply the old rules again, this time with diagnostics.

This situation was far from ideal, as we would sometimes:
* Accept some things we shouldn't.
* Reject some things we shouldn't.
* Only diagnose rejection in terms of the old rules.

With this patch, we apply the P0522 rules throughout.

This needed to extend template argument deduction in order to accept the
historial rule for TTP matching pack parameter to non-pack arguments.
This change also makes us accept some combinations of historical and
P0522 allowances we wouldn't before.

It also fixes a bunch of bugs that were documented in the test suite,
which I am not sure there are issues already created for them.

This causes a lot of changes to the way these failures are diagnosed,
with related test suite churn.

The problem here is that the old rules were very simple and
non-recursive, making it easy to provide customized diagnostics, and to
keep them consistent with each other.

The new rules are a lot more complex and rely on template argument
deduction, substitutions, and they are recursive.

The approach taken here is to mostly rely on existing diagnostics, and
create a new instantiation context that keeps track of things.

So for example when a substitution failure occurs, we use the error
produced there unmodified, and just attach notes to it explaining that
it occurred in the context of partial ordering this template argument
against that template parameter.

This diverges from the old diagnostics, which would lead with an error
pointing to the template argument, explain the problem in subsequent
notes, and produce a final note pointing to the parameter.

show more ...


Revision tags: llvmorg-19.1.1, llvmorg-19.1.0
# b8d6885f 06-Sep-2024 Daniil Fukalov <dfukalov@gmail.com>

[NFC] Add explicit #include llvm-config.h where its macros are used, clang part. (#107301)

(this is clang related part)

Without these explicit includes, removing other headers, who implicitly
in

[NFC] Add explicit #include llvm-config.h where its macros are used, clang part. (#107301)

(this is clang related part)

Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial side effects. For example,
`clagd` may report even `llvm-config.h` as "no used" in case it defines
a macro, that is explicitly used with #ifdef. It is actually amplified
with different build configs which use different set of macros.

show more ...


Revision tags: llvmorg-19.1.0-rc4
# 2cbd1bc8 03-Sep-2024 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

Revert "[C++20] [Modules] Embed all source files for C++20 Modules (#102444)"

This reverts commit 2eeeff842f993a694159183a2834b4d305549cad.

See the post commit discussion in
https://github.com/llvm

Revert "[C++20] [Modules] Embed all source files for C++20 Modules (#102444)"

This reverts commit 2eeeff842f993a694159183a2834b4d305549cad.

See the post commit discussion in
https://github.com/llvm/llvm-project/commit/2eeeff842f993a694159183a2834b4d305549cad

show more ...


# 2eeeff84 29-Aug-2024 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

[C++20] [Modules] Embed all source files for C++20 Modules (#102444)

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

The implementation rationale is, I don't want to pass
`-fmodules-embe

[C++20] [Modules] Embed all source files for C++20 Modules (#102444)

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

The implementation rationale is, I don't want to pass
`-fmodules-embed-all-files` all the time since we can't test it in lit
tests (we're using `clang_cc1`). So I tried to set it in FrontendActions
for modules.

show more ...


Revision tags: llvmorg-19.1.0-rc3
# 43571755 08-Aug-2024 Volodymyr Sapsai <vsapsai@apple.com>

[re-format][Modules] Follow-up formatting to "Mention which AST file's options differ from the current TU options." (#102484)

Fix formatting for fdf8e3e31103bc81917cdb27150877f524bb2669.


# fdf8e3e3 08-Aug-2024 Volodymyr Sapsai <vsapsai@apple.com>

[Modules][Diagnostic] Mention which AST file's options differ from the current TU options. (#101413)

Claiming a mismatch is always in a precompiled header is wrong and
misleading as a mismatch can

[Modules][Diagnostic] Mention which AST file's options differ from the current TU options. (#101413)

Claiming a mismatch is always in a precompiled header is wrong and
misleading as a mismatch can happen in any provided AST file. Emitting a
path for a file with a problem allows to disambiguate between multiple
input files.

Use generic term "AST file" because we don't always know a kind of the
provided file (for example, see `ASTReader::readASTFileControlBlock`).

rdar://65005546

show more ...


Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init
# bf4167fd 11-Jul-2024 Dmitriy Chestnykh <dm.chestnykh@gmail.com>

[Clang] Don't crash if input file is not a module. (#98439)

Currently clang crashes with `-module-file-info` and input file which is
not a module
Emit error instead of segfaulting.
Fix #98365


Revision tags: llvmorg-18.1.8, llvmorg-18.1.7
# 0559eaff 05-Jun-2024 Nishith Kumar M Shah <nishithshah.2211@gmail.com>

Revert "Pass LangOpts from CompilerInstance to DependencyScanningWorker (#93753)" (#94488)

This reverts commit 9862080b1cbf685c0d462b29596e3f7206d24aa2.


# 9862080b 03-Jun-2024 Nishith Kumar M Shah <nishithshah2211@users.noreply.github.com>

Pass LangOpts from CompilerInstance to DependencyScanningWorker (#93753)

This commit fixes https://github.com/llvm/llvm-project/issues/88896 by
passing LangOpts from the CompilerInstance to
Depend

Pass LangOpts from CompilerInstance to DependencyScanningWorker (#93753)

This commit fixes https://github.com/llvm/llvm-project/issues/88896 by
passing LangOpts from the CompilerInstance to
DependencyScanningWorker so that the original LangOpts are
preserved/respected.
This makes for more accurate parsing/lexing when certain language
versions or features specific to versions are to be used.

show more ...


# a41a20bd 03-Jun-2024 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

[NFC] [C++20] [Modules] [Reduced BMI] Reorder Emitting reduced BMI and normal BMI for named modules

When we generate the reduced BMI on the fly, the order of the emitting
phase is different within `

[NFC] [C++20] [Modules] [Reduced BMI] Reorder Emitting reduced BMI and normal BMI for named modules

When we generate the reduced BMI on the fly, the order of the emitting
phase is different within `-emit-obj` and `-emit-module-interface`.
Although this is meant to be fine, we observed it in
https://github.com/llvm/llvm-project/issues/93859 (that the different phase order may cause problems).
Also it turns out to be a different fundamental reason to the orders.

But it might be fine to make the order of emitting reducing BMI at first
to avoid such confusions in the future.

show more ...


Revision tags: llvmorg-18.1.6, llvmorg-18.1.5
# fce09169 30-Apr-2024 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

[NFC] [C++20] [Modules] Use new class CXX20ModulesGenerator to genera… (#90570)

…te module file for C++20 modules instead of PCHGenerator

Previously we're re-using PCHGenerator to generate the mo

[NFC] [C++20] [Modules] Use new class CXX20ModulesGenerator to genera… (#90570)

…te module file for C++20 modules instead of PCHGenerator

Previously we're re-using PCHGenerator to generate the module file for
C++20 modules. But this is slighty more or less odd. This patch tries to
use a new class 'CXX20ModulesGenerator' to generate the module file for
C++20 modules.

show more ...


# ec527b21 30-Apr-2024 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

[C++20] [Modules] Don't skip pragma diagnostic mappings

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

Previously, I thought the diagnostic mappings is not meaningful with
modules incorrec

[C++20] [Modules] Don't skip pragma diagnostic mappings

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

Previously, I thought the diagnostic mappings is not meaningful with
modules incorrectly. And this problem get revealed by another change
recently. So this patch tried to rever the previous "optimization"
partially.

show more ...


# 6b961e2a 30-Apr-2024 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

Revert "[C++20] [Modules] Don't skip pragma diagnostic mappings"
and "[NFC] [C++20] [Modules] Use new class CXX20ModulesGenerator to
generate module file for C++20 modules instead of PCHGenerator"

T

Revert "[C++20] [Modules] Don't skip pragma diagnostic mappings"
and "[NFC] [C++20] [Modules] Use new class CXX20ModulesGenerator to
generate module file for C++20 modules instead of PCHGenerator"

This reverts commit fb21343473e33e9a886b42d2fe95d1cec1cd0030.
and commit 18268ac0f48d93c2bcddb69732761971669c09ab.

It looks like there are some problems about linking the compiler

show more ...


# 18268ac0 30-Apr-2024 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

[NFC] [C++20] [Modules] Use new class CXX20ModulesGenerator to generate module file for C++20 modules instead of PCHGenerator

Previously we're re-using PCHGenerator to generate the module file for
C

[NFC] [C++20] [Modules] Use new class CXX20ModulesGenerator to generate module file for C++20 modules instead of PCHGenerator

Previously we're re-using PCHGenerator to generate the module file for
C++20 modules. But this is slighty more or less odd. This patch tries
to use a new class 'CXX20ModulesGenerator' to generate the module file
for C++20 modules.

show more ...


Revision tags: llvmorg-18.1.4
# f811d7b5 15-Apr-2024 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

[C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (#85050)

This is the driver part of
https://github.com/llvm/llvm-project/pull/75894.

This patch introduces '-fexperimental-modules-

[C++20] [Modules] Introduce -fexperimental-modules-reduced-bmi (#85050)

This is the driver part of
https://github.com/llvm/llvm-project/pull/75894.

This patch introduces '-fexperimental-modules-reduced-bmi' to enable
generating the reduced BMI.

This patch did:
- When `-fexperimental-modules-reduced-bmi` is specified but
`--precompile` is not specified for a module unit, we'll skip the
precompile phase to avoid unnecessary two-phase compilation phases. Then
if `-c` is specified, we will generate the reduced BMI in CodeGenAction
as a by-product.
- When `-fexperimental-modules-reduced-bmi` is specified and
`--precompile` is specified, we will generate the reduced BMI in
GenerateModuleInterfaceAction as a by-product.
- When `-fexperimental-modules-reduced-bmi` is specified for a
non-module unit. We don't do anything nor try to give a warn. This is
more user friendly so that the end users can try to test and experiment
with the feature without asking help from the build systems.

The core design idea is that users should be able to enable this easily
with the existing cmake mechanisms.

The future plan for the flag is:
- Add this to clang19 and make it opt-in for 1~2 releases. It depends on
the testing feedback to decide how long we like to make it opt-in.
- Then we can announce the existing BMI generating may be deprecated and
suggesting people (end users or build systems) to enable this for 1~2
releases.
- Finally we will enable this by default. When that time comes, the term
`BMI` will refer to the reduced BMI today and the existing BMI will only
be meaningful to build systems which loves to support two phase
compilations.

I'll send release notes and document in seperate commits after this get
landed.

show more ...


# 2248164a 09-Apr-2024 Jan Svoboda <jan_svoboda@apple.com>

Revert "[clang] Move state out of `PreprocessorOptions` (1/n) (#86358)"

This reverts commit 407a2f23 which stopped propagating the callback to module compiles, effectively disabling dependency direc

Revert "[clang] Move state out of `PreprocessorOptions` (1/n) (#86358)"

This reverts commit 407a2f23 which stopped propagating the callback to module compiles, effectively disabling dependency directive scanning for all modular dependencies. Also added a regression test.

show more ...


# f7d93373 09-Apr-2024 Younan Zhang <zyn7109@gmail.com>

[Sema][NFC] Cleanups after 843cc474f (#87996)

I forgot to tidy up these lines that should've been done in the previous
commit, specifically:

1. Merge two `CodeSynthesisContext`s into one in `Che

[Sema][NFC] Cleanups after 843cc474f (#87996)

I forgot to tidy up these lines that should've been done in the previous
commit, specifically:

1. Merge two `CodeSynthesisContext`s into one in `CheckTemplateIdType`.
2. Remove some gratuitous `Sema::` specifiers.
3. Rename the parameter `Template` to `Entity` to avoid confusion.

show more ...


# 843cc474 05-Apr-2024 Younan Zhang <zyn7109@gmail.com>

[Clang][Sema] Fix the lambda call expression inside of a type alias declaration (#82310)

This patch attempts to fix the lambda call expression inside of a type
alias declaration from two aspects:

[Clang][Sema] Fix the lambda call expression inside of a type alias declaration (#82310)

This patch attempts to fix the lambda call expression inside of a type
alias declaration from two aspects:
1. Defer the lambda call expression building until after we have
sufficient template arguments. This avoids the overeager (and often
wrong) semantic checking before the type alias instantiation.
2. Properly obtain template arguments involving a template type alias
for constraint checking.

It is unfortunate that a `TypeAliasTemplateDecl` (or a `TypeAliasDecl`)
is never a `DeclContext`, nor does it have an associated specialization
Decl from which we could collect these template arguments. Thus, I added
a new CodeSynthesisContext to record template arguments for alias
declarations.

Fixes https://github.com/llvm/llvm-project/issues/70601
Fixes https://github.com/llvm/llvm-project/issues/76674
Fixes https://github.com/llvm/llvm-project/issues/79555
Fixes https://github.com/llvm/llvm-project/issues/81145
Fixes https://github.com/llvm/llvm-project/issues/82104

Note that this doesn't involve the fix for
https://github.com/llvm/llvm-project/issues/28461. That seems different,
and I'd like to leave it as a follow-up.

show more ...


Revision tags: llvmorg-18.1.3
# 407a2f23 29-Mar-2024 Jan Svoboda <jan_svoboda@apple.com>

[clang] Move state out of `PreprocessorOptions` (1/n) (#86358)

An instance of `PreprocessorOptions` is part of `CompilerInvocation`
which is supposed to be a value type. The `DependencyDirectivesFo

[clang] Move state out of `PreprocessorOptions` (1/n) (#86358)

An instance of `PreprocessorOptions` is part of `CompilerInvocation`
which is supposed to be a value type. The `DependencyDirectivesForFile`
member is problematic, since it holds an owning reference of the
scanning VFS. This makes it not a true value type, and it can keep
potentially large chunk of memory (the local cache in the scanning VFS)
alive for longer than clients might expect. Let's move it into the
`Preprocessor` instead.

show more ...


12345678910>>...14