Close https://github.com/llvm/llvm-project/issues/63544.
Background: We landed std modules in libcxx recently but we haven't
landed the corresponding in-tree tests. According to @Mordante, there
are only 1% libcxx tests failing with std modules. And the major
blocking issue is the lambda expression in the require clauses.
The root cause of the issue is that previously we never consider any
lambda expression as the same. Per [temp.over.link]p5:
> Two lambda-expressions are never considered equivalent.
I thought this is an oversight at first but @rsmith explains that in the
wording, the program is as if there is only a single definition, and a
single lambda-expression. So we don't need worry about this in the spec.
The explanation makes sense. But it didn't reflect to the implementation
directly.
Here is a cycle in the implementation. If we want to merge two
definitions, we need to make sure its implementation are the same. But
according to the explanation above, we need to judge if two
lambda-expression are the same by looking at its parent definitions. So
here is the problem.
To solve the problem, I think we have to profile the lambda expressions
actually to get the accurate information. But we can't do this
universally. So in this patch I tried to modify the interface of
`Stmt::Profile` and only profile the lambda expression during the
process of merging the constraint expressions.
Differential Revision: https://reviews.llvm.org/D153957
This comes from https://reviews.llvm.org/D153003
By @rsmith, the test case is valid since:
> Per [temp.type]/1.4 (http://eel.is/c++draft/temp.type#1.4),
>
>> Two template-ids are the same if [...] their corresponding template
>> template-arguments refer to the same template.
> so B<A> and B<NS::A> are the same type. The stricter "same sequence of
> tokens" rule doesn't apply here, because using-declarations are not
> definitions.
> we should either (preferably) be including only the syntactic form of
> the base specifier (because local syntax is what the ODR covers), or
> the canonical type (which should be the same for both
> using-declarations).
Here we adopt the second suggested solutions.
Reviewed By: cor3ntin, v.g.vassilev
Differential Revision: https://reviews.llvm.org/D154324
The itanium ABI for certain platforms requires a minimum alignments for
member function pointers to reserve certain bits for distinguishing
virtual and non-virtual functions.
Our implementation of this however depends on the alignment of the
function involved, which may however not reflect the true alignment of
function pointers on certain targets for which the alignment is
independent of the function (e.g. AIX). Worse, the 2-byte alignment
we use may be less than the ABI minimum for the target, and in the case
we are using explicit sections will result in invalid codegen.
This patch attempts to correct this situation by considering the target
alignment of function pointers as part of making the decision about
whether we need to adjust the function alignment to conform to the ABI.
Targets which do not provide the function ptr alignment information
will return a value of 1 when queried and will conservatively retain
the old alignment.
Differential Revision: https://reviews.llvm.org/D147184
`isPropertyAccessor` depends on the surrounding code and not on the method
itself. That's why it can be different in different modules. And
mismatches shouldn't be an error.
rdar://109481753
Differential Revision: https://reviews.llvm.org/D154460
`isOverriding` depends on the surrounding code and not on the method
itself. That's why it can be different in different modules. And
mismatches shouldn't be an error.
rdar://109481753
Differential Revision: https://reviews.llvm.org/D154459
When writing a pcm, we serialize diagnostic mappings in order to
accurately reproduce the diagnostic environment inside any headers from
that module. However, the diagnostic state mapping table contains
entries for every diagnostic ID ever accessed, while we only want to
serialize the ones that are actually modified from their default value.
Futher, we need to serialize them in a deterministic order.
rdar://111477511
Differential Revision: https://reviews.llvm.org/D154016
It has been reported to that the current clang errors for, specifically,
static_assert in export contexts are a serious blocker to adoption of
modules in some cases.
There is also implementation divergence with GCC and MSVC allowing the
constructs mentioned below where clang currently rejects them with an
error.
The category of errors [for declarations in an exported context] is:
(unnamed, static_assert, empty and asm decls). These are now permitted
after P2615R1 which was approved by WG21 as a DR (and thus should be
applied to C++20 as well).
This patch removes these diagnostics and amends the testsuite accordingly.
Differential Revision: https://reviews.llvm.org/D152946
Close https://github.com/llvm/llvm-project/issues/62943.
The root cause for the issue is that we think the associated constraints
from the 'same' declaration in different module units are different
incorrectly. Since the constraints doesn't know anything about decls and
modules, we should fix the problem by getting the associated constraints
from the exactly the same declarations from different modules.
In D152070 we added many new intrinsic types required for the RISC-V
Vector Extension.
This was crashing when loading the AST as those types are intrinsically
added to the AST (they don't come from the disk).
The total number required now by clang exceeds 400 so increasing the
value to 500 solves the problem. This value was already increased in
D92715 but I assume this has some impact on the on-disk format.
Also add a static assert to avoid this happening again in the future.
Differential Revision: https://reviews.llvm.org/D153111
s390x looks through pointers when determining the "externally
visible vector ABI". For that reason, the test shows different
behavior just on that platform.
Adjust the test in the reverse direction of what I originall did:
Make sure that the type behind the pointer is always queried, by
dereferencing the pointer.
When modules are disabled, there's no loaded module for these import
decls to point at. This results in crashes when there are modulemap
files but no -fmodules flag (this configuration is used for layering
check violations).
This patch makes sure import declarations are introduced only when
modules are enabled, which makes this case similar to textual headers
(no import decls are created for #include of textual headers from a
modulemap).
Differential Revision: https://reviews.llvm.org/D152274
This patch removes some deprecated uses of `{File,Directory}Entry::getName()`. No functional change intended.
Depends on D151854.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D151855
In CGTypes, directly create opaque pointers, without computing the
LLVM element type. This is not as straightforward as I though it
would be, because apparently computing the LLVM type also causes a
number of side effects.
In particular, we no longer produce diagnostics like -Wpacked for
typed (only) behind pointers, because we no longer depend on their
layout.
Differential Revision: https://reviews.llvm.org/D152505
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
On some systems, the second `split-file` command will fail because the current
directory is the one we have deleted, we switch to another directory
before running it.
Previously, if a header was found via in a header map, and not just remapped.
we wouldn't also find the module it maps to when using implicit modules (for
module maps that were explicitly loaded).
This diff just updates these code paths to also locate the owning module via
`findUsableModuleForHeader`.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D103930
For redirected file entries, `FileEntryRef::getDir()` returns the parent directory entry of the target file entry. This differs from `FileEntry::getDir()` that always returns the parent directory that was last used to look up that file.
After switching from `FileEntry` to `FileEntryRef` for umbrella headers in D142113, this discrepancy became observable and caused Clang to emit incorrect diagnostics.
This patch changes Clang so that it always associates `FileEntryRef` with the parent directory that was used to look it up. This brings its behavior closer to `FileEntry`, but without the hacky mutation.
This also ensures that `llvm::sys::path::parent_path(FileRef->getNameAsRequested()) == FileRef->getDir()->getName()`. Previously, `FileRef->getDir()` would fall underneath the redirecting VFS into the world of on-disk paths.
Reviewed By: benlangmuir, rmaz
Differential Revision: https://reviews.llvm.org/D151398
Close https://github.com/llvm/llvm-project/issues/62796.
Previously, we didn't serialize the evaluated result for VarDecl. This
caused the compilation of template metaprogramming become slower than
expect. This patch fixes the issue.
This is a recommit tested with asan built clang.
Decl::isInAnotherModuleUnit
Refactor `Sema::isModuleUnitOfCurrentTU` to `Decl::isInAnotherModuleUnit`
to make code simpler a little bit. Note that although this patch
introduces a FIXME, this is an existing issue and this patch just tries
to describe it explicitly.
Currently, the header units are rarely used and it is not well tested.
To avoid further misunderstandings, let's mark it as experimental and
emit a warning when users wants to import it.
This is discussed in modules developers meeting.
Add cplusplus20, cplusplus23, and cplusplus26 (but don't document
the latter, following the current policy).
Differential Revision: https://reviews.llvm.org/D150773
A step to address https://github.com/llvm/llvm-project/issues/62707.
It is not user friendly enough to drop the implicitly generated path
directly. Let's emit the warning first and drop it in the next version.
ASTReader after we start writing
This is intended to mitigate
https://github.com/llvm/llvm-project/issues/61447.
Before the patch, it takes 5s to compile test.cppm in the above
reproducer. After the patch it takes 3s to compile it. Although this
patch didn't solve the problem completely, it should mitigate the
problem for sure. Noted that the behavior of the patch is consistent
with the comment of the originally empty function
ASTReader::finalizeForWriting. So the change should be consistent with
the original design.
even if its initializer has side effects
Close https://github.com/llvm/llvm-project/issues/61892
The variables whose initializer has side effects will be emitted even if
it is not used. But it shouldn't be true after we introduced modules.
The variables in other modules shouldn't be emitted if it is not used
even if its initializer has size effects.
Also this patch rename `Decl::isInCurrentModuleUnit` to
`Decl::isInAnotherModuleUnit` to make it closer to the semantics.
Previously, if a class with a defined public virtual destructor is
declared before including <initializer_list> and initializer_list is
provided via a Clang module, then overload resolution would fail for
std::initializer_list. This is because when Clang sees the virtual
destructor, Clang creates an implicit NamespaceDecl for std to
implicitly declare a std::bad_alloc. That NamespaceDecl is not added to
the translation unit's lookup table, so when the module containing
std::initializer_list is imported later, that module's std NamespaceDecl
can't find the previous std NamespaceDecl during redeclaration lookup,
causing overload resolution to fail.
To fix this, implicitly created std NamespaceDecls are now added to the
lookup map. At the same time, their IdentifierNamespace members are
cleared to prevent regular name lookups from finding it.
Fixes 60929
Reviewed By: ChuanqiXu, #clang-language-wg, inclyc
Differential Revision: https://reviews.llvm.org/D150001
Close https://github.com/llvm/llvm-project/issues/62589.
Previously, for global module fragments, we will justify if it is
visible by the visibility of their top level parents. But this is an
overkill, it is problematic if we have a deduction guide in the global
module fragments. See the attached test for example. In this example, we
will mark the global module fragments as visible, but our old strategy
will miss the case surprisingly due to we will only search for the top
level modules.
Close https://github.com/llvm/llvm-project/issues/62269
Currently, the compiler will emit errors when we compile C++20 modules
if the referenced files changed or got removed. This is because we reuse
the existing logic from Clang implicit modules. It is helpful for clang
implicit modules since it is implicit and we want to be sure things
don't go wrong. But it is not necessary for C++20 modules. The C++20
modules is explicit and it is build systems' responsibility to maintain
the dependencies. So the check in the compiler side may be an overkill.
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.
This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.
Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D149553
This reverts commit 67b298f6d82e0b4bb648ac0dabe895e816a77ef1.
We got linker errors with undefined symbols during a compiler release
and tracked it down to this change. I am in the process of understanding
what is happening and getting a reproducer.
Sorry for reverting this again.
I will reopen#61065 until we fix this.
We only want to make PCH imports visible once for the the TU, not
repeatedly after every subsequent import. This causes some incorrect
behaviour with submodule visibility, and causes us to get extra module
dependencies in the scanner. So far I have only seen obviously incorrect
behaviour when building with -fmodule-name to cause a submodule to be
textually included when using the PCH, though the old behaviour seems
wrong regardless.
rdar://107449644
Differential Revision: https://reviews.llvm.org/D148176
Fixes#61065.
This reverts commit 363c98b2d67986b9766bb1426739970ce6d9a6f3 and relands
db987b9589be1eb604fcb74c85b410469e31485f with fixes from
bc95f27337c7ed77c28e713c855272848f01802a.
The module-related issues surfaced there are fixed in the
previous commit.
Classes can have implicit members that were added before fields were
deserialized. These members were previously silently removed from
`decls()` when fields were deserialized after them.
This was the root cause of a compilation error exposed in
bc95f27337c7ed77c28e713c855272848f01802a, added a test for it.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D148515
This reverts commit bc95f27337c7ed77c28e713c855272848f01802a, originally db987b9589be1eb604fcb74c85b410469e31485f.
clang/test/Modules/pr61065.cppm is retained to make relands show less diff.
There are other module-related issues that were not caught, related to
false positive errors like
"error: no matching constructor for initialization of 'union (anonymous union at ..."
Reopen#61065
Close https://github.com/llvm/llvm-project/issues/62112
In the previous change, we'll stop parsing directly after we found
reserved module names. But this may be too aggressive. This patch
changes this. Note that the parsing will still be stopped if the module
name is `module` or `import`.
Add missing "REQUIRES: asserts" for the two tests added in commit
711a64412749ae73709562b591ab1609a3ee7751 (Diff: D145803).
Reviewed By: chapuni
Differential Revision: https://reviews.llvm.org/D147764
With this patch, whenever we emit a `DW_AT_type` for some declaration
and the type is a template class with a `clang::PreferredNameAttr`, we
will emit the typedef that the attribute refers to instead. I.e.,
```
0x123 DW_TAG_variable
DW_AT_name "var"
DW_AT_type (0x123 "basic_string<char>")
0x124 DW_TAG_structure_type
DW_AT_name "basic_string<char>"
```
...becomes
```
0x123 DW_TAG_variable
DW_AT_name "var"
DW_AT_type (0x124 "std::string")
0x124 DW_TAG_structure_type
DW_AT_name "basic_string<char>"
0x125 DW_TAG_typedef
DW_AT_name "std::string"
DW_AT_type (0x124 "basic_string<char>")
```
We do this by returning the preferred name typedef `DIType` when
we create a structure definition. In some cases, e.g., with `-gmodules`,
we don't complete the structure definition immediately but do so later
via `completeClassData`, which overwrites the `TypeCache`. In such cases
we don't actually want to rewrite the cache with the preferred name. We
handle this by returning both the definition and the preferred typedef
from `CreateTypeDefinition` and let the callee decide what to do with
it.
Essentially we set up the types as:
```
TypeCache[Record] => DICompositeType
ReplaceMap[Record] => DIDerivedType(baseType: DICompositeType)
```
For now we keep this behind LLDB tuning.
**Testing**
- Added clang unit-test
- `check-llvm`, `check-clang` pass
- Confirmed that this change correctly repoints
`basic_string` references in some of my test programs.
- Will add follow-up LLDB API tests
Differential Revision: https://reviews.llvm.org/D145803
This re-lands commit db987b9589be1eb604fcb74c85b410469e31485f,
previously reverted in commit 1e0709167f5edd330889f51bb203c458bdb5e359,
with a fix for a pre-existing bug in how we write constructor names into
lookup tables that was exposed by that change.
As yet, we've been unable to produce a reduced testcase for this bug,
but we understand the problem: if we write out a lookup table for a
class which has two constructor names, and we only have local lookup
results for one of those constructor names, then we will write out a
lookup table where the "all the constructors" lookup result contains
results for only one of the constructor names.
