Revision tags: 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 |
|
#
0f59bee3 |
| 05-May-2023 |
Roy Jacobson <roi.jacobson1@gmail.com> |
[Sema] Mark ineligibility of special member functions correctly
I checked if the member function declaration was a copy constructor, but it's not sufficient; We need to check the arguments against t
[Sema] Mark ineligibility of special member functions correctly
I checked if the member function declaration was a copy constructor, but it's not sufficient; We need to check the arguments against the instantiated class.
Fixed https://github.com/llvm/llvm-project/issues/62555
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D149961
show more ...
|
Revision tags: llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4 |
|
#
000ec50e |
| 22-Feb-2023 |
Roy Jacobson <roi.jacobson1@gmail.com> |
[Clang] Adjust triviality computation in QualType::isTrivialType to C++20 cases.
Up to C++20, hasDefaultConstructor and !hasNonTrivialDefaultConstructor together implied hasTrivialDefaultConstructor
[Clang] Adjust triviality computation in QualType::isTrivialType to C++20 cases.
Up to C++20, hasDefaultConstructor and !hasNonTrivialDefaultConstructor together implied hasTrivialDefaultConstructor. In C++20, a constructor might be ineligible and can set hasDefaultConstructor without setting hasNonTrivialDefaultConstructor.
Fix this by querying hasTrivialDefaultConstructor instead of hasDefaultConstructor.
I'd like to backport this to Clang 16. I only change isTrivialType and in a way that should only affect code that uses constrained constructors, so I think this is relatively safe to backport.
Fixes https://github.com/llvm/llvm-project/issues/60697
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D143891
show more ...
|
Revision tags: llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
7d58c956 |
| 04-Dec-2022 |
Roy Jacobson <roi.jacobson1@gmail.com> |
[Clang] Don't consider default constructors ineligible if the more constrained constructor is a template
Partially solves https://github.com/llvm/llvm-project/issues/59206:
We now mark trivial cons
[Clang] Don't consider default constructors ineligible if the more constrained constructor is a template
Partially solves https://github.com/llvm/llvm-project/issues/59206:
We now mark trivial constructors as eligible even if there's a more constrained templated default constructor. Although technically non-conformant, this solves problems with pretty reasonable uses cases like ``` template<int n> struct Foo { constexpr Foo() = default;
template<class... Ts> Foo(Ts... vals) requires(sizeof...(Ts) == n) {} }; ``` where we currently consider the default constructor to be ineligible and therefor inheriting/containing classes have non trivial constructors. This is aligned with GCC: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c75ebe76ae12ac4020f20a24f34606a594a40d15
This doesn't change `__is_trivial`. Although we're technically standard conformant in this regard, GCC/MSVC exhibit different behaviors that seem to make more sense. An issue has been filed to CWG and we await their response.
Reviewed By: erichkeane, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D139038
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3 |
|
#
babdef27 |
| 19-Aug-2022 |
Erich Keane <erich.keane@intel.com> |
Re-apply "Deferred Concept Instantiation Implementation"
This reverts commit 95d94a67755620c0a2871ac6f056ca8e9731d5e9.
This implements the deferred concepts instantiation, which should allow the li
Re-apply "Deferred Concept Instantiation Implementation"
This reverts commit 95d94a67755620c0a2871ac6f056ca8e9731d5e9.
This implements the deferred concepts instantiation, which should allow the libstdc++ ranges to properly compile, and for the CRTP to work for constrained functions.
Since the last attempt, this has fixed the issues from @wlei and @mordante.
Differential Revision: https://reviews.llvm.org/D126907
show more ...
|
#
b1c960fc |
| 25-Aug-2022 |
Roy Jacobson <roi.jacobson1@gmail.com> |
[Clang] Implement P0848 (Conditionally Trivial Special Member Functions)
This patch implements P0848 in Clang.
During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constrain
[Clang] Implement P0848 (Conditionally Trivial Special Member Functions)
This patch implements P0848 in Clang.
During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions.
Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise.
Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman
Differential Revision: https://reviews.llvm.org/D128619
show more ...
|
#
71716150 |
| 22-Aug-2022 |
Roy Jacobson <roi.jacobson1@gmail.com> |
[Clang] Implement P0848 (Conditionally Trivial Special Member Functions)
This patch implements P0848 in Clang.
During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constrain
[Clang] Implement P0848 (Conditionally Trivial Special Member Functions)
This patch implements P0848 in Clang.
During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions.
Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise.
Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman
Differential Revision: https://reviews.llvm.org/D128619
show more ...
|