|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
a2772fc8 |
| 22-Jul-2022 |
Chuanqi Xu <[email protected]> |
[C++20] [Modules] Disable preferred_name when writing a C++20 Module interface
Currently, the use of preferred_name would block implementing std modules in libcxx. See https://github.com/llvm/llvm-p
[C++20] [Modules] Disable preferred_name when writing a C++20 Module interface
Currently, the use of preferred_name would block implementing std modules in libcxx. See https://github.com/llvm/llvm-project/issues/56490 for example. The problem is pretty hard and it looks like we couldn't solve it in a short time. So we sent this patch as a workaround to avoid blocking us to modularize STL. This is intended to be fixed properly in the future.
Reviewed By: erichkeane, aaron.ballman, tahonermann
Differential Revision: https://reviews.llvm.org/D130331
show more ...
|
| #
3ff86f96 |
| 22-Jul-2022 |
Erich Keane <[email protected]> |
[NFC] Start saving InstantiatedFromDecl in non-template functions
In cases where a non-template function is defined inside a function template, we don't have information about the original uninstant
[NFC] Start saving InstantiatedFromDecl in non-template functions
In cases where a non-template function is defined inside a function template, we don't have information about the original uninstantiated version. In the case of concepts instantiation, we will need the ability to get back to the original template. This patch splits a piece of the deferred concepts instantaition patch off to accomplish the storage of this, with minor runtime overhead, and zero additional storage.
show more ...
|
| #
258c3aee |
| 01-Jul-2022 |
Erich Keane <[email protected]> |
Revert "Re-apply "Deferred Concept Instantiation Implementation"""
This reverts commit befa8cf087dbb8159a4d9dc8fa4d6748d6d5049a.
Apparently this breaks some libc++ builds with an apparent assertion
Revert "Re-apply "Deferred Concept Instantiation Implementation"""
This reverts commit befa8cf087dbb8159a4d9dc8fa4d6748d6d5049a.
Apparently this breaks some libc++ builds with an apparent assertion, so I'm looking into that .
show more ...
|
| #
befa8cf0 |
| 30-Jun-2022 |
Erich Keane <[email protected]> |
Re-apply "Deferred Concept Instantiation Implementation""
This reverts commit d4d47e574ecae562ab32f8ac7fa3f4d424bb6574.
This fixes the lldb crash that was observed by ensuring that our friend-'temp
Re-apply "Deferred Concept Instantiation Implementation""
This reverts commit d4d47e574ecae562ab32f8ac7fa3f4d424bb6574.
This fixes the lldb crash that was observed by ensuring that our friend-'template contains reference to' TreeTransform properly handles a TemplateDecl.
show more ...
|
| #
d4d47e57 |
| 30-Jun-2022 |
Jonas Devlieghere <[email protected]> |
Revert "Deferred Concept Instantiation Implementation"
This reverts commit 2f207439521d62d9551b2884158368e8b34084e5 because it triggers an assertion when building an LLDB test program:
Assertion
Revert "Deferred Concept Instantiation Implementation"
This reverts commit 2f207439521d62d9551b2884158368e8b34084e5 because it triggers an assertion when building an LLDB test program:
Assertion failed: (InstantiatingSpecializations.empty() && "failed to clean up an InstantiatingTemplate?"), function ~Sema, file /Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/clang/lib/Sema/Sema.cpp, line 458.
More details in https://reviews.llvm.org/D126907.
show more ...
|
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4 |
|
| #
2f207439 |
| 19-May-2022 |
Erich Keane <[email protected]> |
Deferred Concept Instantiation Implementation
This is a continuation of D119544. Based on @rsmith 's feed back showing me https://eel.is/c++draft/temp#friend-9, We should properly handle friend fun
Deferred Concept Instantiation Implementation
This is a continuation of D119544. Based on @rsmith 's feed back showing me https://eel.is/c++draft/temp#friend-9, We should properly handle friend functions now.
Differential Revision: https://reviews.llvm.org/D126907
show more ...
|
| #
9c04851c |
| 29-Jun-2022 |
Chuanqi Xu <[email protected]> |
[C++20] [Module] Support reachable definition initially/partially
This patch introduces a new kind of ModuleOwnershipKind as ReachableWhenImported. This intended the status for reachable described a
[C++20] [Module] Support reachable definition initially/partially
This patch introduces a new kind of ModuleOwnershipKind as ReachableWhenImported. This intended the status for reachable described at: https://eel.is/c++draft/module.reach#3.
Note that this patch is not intended to support all semantics about reachable semantics. For example, this patch didn't implement discarded declarations in GMF. (https://eel.is/c++draft/module.global.frag#3).
This fixes: https://bugs.llvm.org/show_bug.cgi?id=52281 and https://godbolt.org/z/81f3ocjfW.
Reviewed By: rsmith, iains
Differential Revision: https://reviews.llvm.org/D113545
show more ...
|
| #
7a541406 |
| 29-Jun-2022 |
Chuanqi Xu <[email protected]> |
Revert "[C++20] [Modules] Implement Reachable initiallly"
This reverts commit a223ba0a697c1598b434cf2495c9cd9ec5640fc7.
The previous commit don't contain additional information, which is bad.
|
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
| #
a223ba0a |
| 21-Feb-2022 |
Chuanqi Xu <[email protected]> |
[C++20] [Modules] Implement Reachable initiallly
|
| #
16941753 |
| 16-Jun-2022 |
Michael Spencer <[email protected]> |
[Clang][Modules] Merge availability attributes on imported decls
Currently we do not in general merge attributes when importing decls from modules. This patch handles availability, but long term we
[Clang][Modules] Merge availability attributes on imported decls
Currently we do not in general merge attributes when importing decls from modules. This patch handles availability, but long term we need to properly handle all attributes.
I tried to use Sema::mergeDeclAttributes, but it caused test crashes as I don't think it expects to be called in this context. We really shouldn't have duplicate code for merging attributes long term, but for now this fixes availability. There's already a TODO for this in the declaration of ASTDeclReader::mergeInheritableAttributes.
Differential Revision: https://reviews.llvm.org/D127182
rdar://85820301
show more ...
|
| #
017abbb2 |
| 09-May-2022 |
Erich Keane <[email protected]> |
Revert ""Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""""
This reverts commit a425cac31e2e4cee8e14b7b9a99c8ba17c1ebb52.
There is another libc++ test, that this time causes us
Revert ""Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""""
This reverts commit a425cac31e2e4cee8e14b7b9a99c8ba17c1ebb52.
There is another libc++ test, that this time causes us to hit an assertion. Reverting, likely for a while this time.
show more ...
|
| #
a425cac3 |
| 05-May-2022 |
Erich Keane <[email protected]> |
"Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""""
This includes a fix for the libc++ issue I ran across with friend declarations not properly being identified as overloads.
Th
"Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""""
This includes a fix for the libc++ issue I ran across with friend declarations not properly being identified as overloads.
This reverts commit 45c07db31cc76802a1a2e41bed1ce9c1b8198181.
show more ...
|
| #
45c07db3 |
| 02-May-2022 |
Erich Keane <[email protected]> |
Revert "Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""
This reverts commit a97899108e495147985e5e9492e742d51d5cc97a.
The patch caused some problems with the libc++ `__range_a
Revert "Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation"""
This reverts commit a97899108e495147985e5e9492e742d51d5cc97a.
The patch caused some problems with the libc++ `__range_adaptor_closure` that I haven't been able to figure out the cause of, so I am reverting while I figure out whether this is a solvable problem/issue with the CFE, or libc++ depending on an older 'incorrect' behavior.
show more ...
|
| #
a9789910 |
| 02-May-2022 |
Erich Keane <[email protected]> |
Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""
This reverts commit 0c31da48389754822dc3eecc4723160c295b9ab2.
I've solved the issue with the PointerUnion by making the `Functio
Re-apply 4b6c2cd642 "Deferred Concept Instantiation Implementation""
This reverts commit 0c31da48389754822dc3eecc4723160c295b9ab2.
I've solved the issue with the PointerUnion by making the `FunctionTemplateDecl` pointer be a NamedDecl, that could be a `FunctionDecl` or `FunctionTemplateDecl` depending. This is enforced with an assert.
show more ...
|
| #
0c31da48 |
| 02-May-2022 |
Erich Keane <[email protected]> |
Revert "Deferred Concept Instantiation Implementation"
This reverts commit 4b6c2cd647e9e5a147954886338f97ffb6a1bcfb.
The patch caused numerous ARM 32 bit build failures, since we added a 5th item t
Revert "Deferred Concept Instantiation Implementation"
This reverts commit 4b6c2cd647e9e5a147954886338f97ffb6a1bcfb.
The patch caused numerous ARM 32 bit build failures, since we added a 5th item to the PointerUnion, and went over the 2-bits available in the 32 bit pointers.
show more ...
|
| #
4b6c2cd6 |
| 03-Mar-2022 |
Erich Keane <[email protected]> |
Deferred Concept Instantiation Implementation
As reported here: https://github.com/llvm/llvm-project/issues/44178
Concepts are not supposed to be instantiated until they are checked, so this patch
Deferred Concept Instantiation Implementation
As reported here: https://github.com/llvm/llvm-project/issues/44178
Concepts are not supposed to be instantiated until they are checked, so this patch implements that and goes through significant amounts of work to make sure we properly re-instantiate the concepts correctly.
Differential Revision: https://reviews.llvm.org/D119544
show more ...
|
| #
d32c685e |
| 02-Mar-2022 |
Volodymyr Sapsai <[email protected]> |
[modules] Merge equivalent extensions and diagnose ivar redeclarations for extensions loaded from different modules.
Emitting metadata for the same ivar multiple times can lead to miscompilations. O
[modules] Merge equivalent extensions and diagnose ivar redeclarations for extensions loaded from different modules.
Emitting metadata for the same ivar multiple times can lead to miscompilations. Objective-C runtime adds offsets to calculate ivar position in memory and presence of duplicate offsets causes wrong final position thus overwriting unrelated memory.
Such a situation is impossible with modules disabled as clang diagnoses ivar redeclarations during sema checks after parsing (`Sema::ActOnFields`). Fix the case with modules enabled by checking during deserialization if ivar is already declared. We also support a use case where the same category ends up in multiple modules. We don't want to treat this case as ivar redeclaration and instead merge corresponding ivars.
rdar://83468070
Differential Revision: https://reviews.llvm.org/D121177
show more ...
|
| #
63814be4 |
| 19-Apr-2022 |
Richard Smith <[email protected]> |
[modules] Merge variable template specializations.
|
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init |
|
| #
29444f04 |
| 29-Jan-2022 |
Volodymyr Sapsai <[email protected]> |
[modules] Merge ObjC interface ivars with anonymous types.
Without the fix ivars with anonymous types can trigger errors like
> error: 'TestClass::structIvar' from module 'Target' is not present in
[modules] Merge ObjC interface ivars with anonymous types.
Without the fix ivars with anonymous types can trigger errors like
> error: 'TestClass::structIvar' from module 'Target' is not present in definition of 'TestClass' provided earlier > [...] > note: declaration of 'structIvar' does not match
It happens because types of ivars from different modules are considered to be different. And it is caused by not merging anonymous `TagDecl` from different modules.
To fix that I've changed `serialization::needsAnonymousDeclarationNumber` to handle anonymous `TagDecl` inside `ObjCInterfaceDecl`. But that's not sufficient as C code inside `ObjCInterfaceDecl` doesn't use interface decl as a decl context but switches to its parent (TranslationUnit in most cases). I'm changing that to make `ObjCContainerDecl` the lexical decl context but keeping the semantic decl context intact.
Test "check-dup-decls-inside-objc.m" doesn't reflect a change in functionality but captures the existing behavior to prevent regressions.
rdar://85563013
Differential Revision: https://reviews.llvm.org/D118525
show more ...
|
| #
d6148749 |
| 28-Mar-2022 |
James Y Knight <[email protected]> |
[Clang] Implement __builtin_source_location.
This builtin returns the address of a global instance of the `std::source_location::__impl` type, which must be defined (with an appropriate shape) befor
[Clang] Implement __builtin_source_location.
This builtin returns the address of a global instance of the `std::source_location::__impl` type, which must be defined (with an appropriate shape) before calling the builtin.
It will be used to implement std::source_location in libc++ in a future change. The builtin is compatible with GCC's implementation, and libstdc++'s usage. An intentional divergence is that GCC declares the builtin's return type to be `const void*` (for ease-of-implementation reasons), while Clang uses the actual type, `const std::source_location::__impl*`.
In order to support this new functionality, I've also added a new 'UnnamedGlobalConstantDecl'. This artificial Decl is modeled after MSGuidDecl, and is used to represent a generic concept of an lvalue constant with global scope, deduplicated by its value. It's possible that MSGuidDecl itself, or some of the other similar sorts of things in Clang might be able to be refactored onto this more-generic concept, but there's enough special-case weirdness in MSGuidDecl that I gave up attempting to share code there, at least for now.
Finally, for compatibility with libstdc++'s <source_location> header, I've added a second exception to the "cannot cast from void* to T* in constant evaluation" rule. This seems a bit distasteful, but feels like the best available option.
Reviewers: aaron.ballman, erichkeane
Differential Revision: https://reviews.llvm.org/D120159
show more ...
|
| #
3784e8cc |
| 12-Mar-2022 |
Corentin Jabot <[email protected]> |
[Clang] Fix Unevaluated Lambdas
Unlike other types, when lambdas are instanciated, they are recreated from scratch. When an unevaluated lambdas appear in the type of a function, parameter it is inst
[Clang] Fix Unevaluated Lambdas
Unlike other types, when lambdas are instanciated, they are recreated from scratch. When an unevaluated lambdas appear in the type of a function, parameter it is instanciated in the wrong declaration context, as parameters are transformed before the function.
To support lambda in function parameters, we try to compute whether they are dependant without looking at the declaration context.
This is a short term stopgap solution to avoid clang iceing. A better fix might be to inject some kind of transparent declaration with correctly computed dependency for function parameters, variable templates, etc.
Fixes https://github.com/llvm/llvm-project/issues/50376 Fixes https://github.com/llvm/llvm-project/issues/51414 Fixes https://github.com/llvm/llvm-project/issues/51416 Fixes https://github.com/llvm/llvm-project/issues/51641 Fixes https://github.com/llvm/llvm-project/issues/54296
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D121532
show more ...
|
| #
977b1f57 |
| 17-Feb-2022 |
Kadir Cetinkaya <[email protected]> |
[clang][ASTReader] Fix memory leak while reading FriendTemplateDecls
Allocate on ASTContext, rather than just on heap, so that template parameter lists are freed up.
Differential Revision: https://
[clang][ASTReader] Fix memory leak while reading FriendTemplateDecls
Allocate on ASTContext, rather than just on heap, so that template parameter lists are freed up.
Differential Revision: https://reviews.llvm.org/D120081
show more ...
|
| #
fa4a0f1d |
| 01-Feb-2022 |
Volodymyr Sapsai <[email protected]> |
[modules] Add a flag for TagDecl if it was a definition demoted to a declaration.
For redeclaration chains we maintain an invariant of having only a single definition in the chain. In a single trans
[modules] Add a flag for TagDecl if it was a definition demoted to a declaration.
For redeclaration chains we maintain an invariant of having only a single definition in the chain. In a single translation unit we make sure not to create duplicates. But modules are separate translation units and they can contain definitions for the same symbol independently. When we load such modules together, we need to demote duplicate definitions to keep the AST invariants.
Some AST clients are interested in distinguishing declaration-that-was-demoted-from-definition and declaration-that-was-never-a-definition. For that purpose introducing `IsThisDeclarationADemotedDefinition`. No functional change intended.
rdar://84677782
Differential Revision: https://reviews.llvm.org/D118855
show more ...
|
| #
f85ee6d5 |
| 27-Jan-2022 |
Chuanqi Xu <[email protected]> |
[NFC] [AST] Move isSameEntity into ASTContext
Currently we are trying to implement the semantics of C++ Modules. A big challenge would be the ODR checking. Previously we did this in ASTReader, it wo
[NFC] [AST] Move isSameEntity into ASTContext
Currently we are trying to implement the semantics of C++ Modules. A big challenge would be the ODR checking. Previously we did this in ASTReader, it would handle the cases like: ``` module; export module a_module; import another_module; // check the ODR consistency here ``` or ``` export module m; import a_module; import another_module; // check the ODR consistency here ```
However, it wouldn't handle the case: ``` import another_module; // When we check ODR here, everything looks fine. ```
In the case, the read process is ended. But we need to check the ODR still. To reuse the facility we do in ASTReader, this patch moves the corresponding codes into ASTContext. This should be good since there were facilities like `hasSameTemplateName` and `hasSameType`.
Although the patch is a little bit big, all of the change should be trivial.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D118223
show more ...
|
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
140a6b1e |
| 11-Jan-2022 |
Jennifer Yu <[email protected]> |
[clang][OpenMP5.1] Initial parsing/sema for 'indirect' clause
Differential Revision: https://reviews.llvm.org/D116764
|