4 Commits

Author SHA1 Message Date
Fangrui Song
7e59223ac4 [test] %clang_cc1: remove redundant actions
ParseFrontendArgs takes the last OPT_Action_Group option. The other
actions are overridden.
2024-05-05 10:46:06 -07:00
Chuanqi Xu
da00c60dae
[C++20] [Modules] Introduce reduced BMI (#75894)
Close https://github.com/llvm/llvm-project/issues/71034

See

https://discourse.llvm.org/t/rfc-c-20-modules-introduce-thin-bmi-and-decls-hash/74755

This patch introduces reduced BMI, which doesn't contain the definitions
of functions and variables if its definitions won't contribute to the
ABI.

Testing is a big part of the patch. We want to make sure the reduced BMI
contains the same behavior with the existing and relatively stable
fatBMI. This is pretty helpful for further reduction.

The user interfaces part it left to following patches to ease the
reviewing.
2024-03-08 10:12:51 +08:00
Chuanqi Xu
1ba93c3c30 [Modules] Don't re-generate template specialization in the importer
Close https://github.com/llvm/llvm-project/issues/60693.

In this issue, we can find that the importer will try to generate the
template specialization again in the importer, which is not good and
wastes time. This patch tries to address the problem.
2023-02-14 17:15:33 +08:00
Chuanqi Xu
367e618fd6 [C++20] [Modules] Emit full specialization of variable template as available externally in importers
Closes https://github.com/llvm/llvm-project/issues/59780.

In this issue report, when we use full specialization of variable
templates in modules, we will meet the multiple definition errors.

The root cause of the problem is that when we see the full
specialization of the variable template in the importers, we will find
if it is already defined in the external sources and we failed to find
such definitions from external sources. So we generate the definition in
the current TU. We failed to find the definition in the external sources
because we restricted to not write it during writing. However, we don't
know why we restricted it and it doesn't make a lot sense to do such
restriction. Then no test fails after we remove such limitations. So
let's remove it now and add it back later if we found it is necessary
then we can add the corresponding test that time.

Note that the code is only applied to named modules and
PCHWithObjectFiles. So it won't affect the normal clang modules and
header units.
2023-01-03 14:48:29 +08:00