This reverts 4d10c1165442cbbbc0017b48fcdd7dae1ccf3678 and its two dependent commits: e6b9805b574bb5c90263ec7fbcb94df76d2807a4 and c243406a695ca056a07ef4064b0f9feee7685320, see discussion in https://github.com/llvm/llvm-project/pull/165598#issuecomment-3563825509.
MSVC supports an extension allowing to delete an array of objects via pointer whose static type doesn't match its dynamic type. This is done via generation of special destructors - vector deleting destructors. MSVC's virtual tables always contain a pointer to the vector deleting destructor for classes with virtual destructors, so not having this extension implemented causes clang to generate code that is not compatible with the code generated by MSVC, because clang always puts a pointer to a scalar deleting destructor to the vtable. As a bonus the deletion of an array of polymorphic object will work just like it does with MSVC - no memory leaks and correct destructors are called. This patch will cause clang to emit code that is compatible with code produced by MSVC but not compatible with code produced with clang of older versions, so the new behavior can be disabled via passing -fclang-abi-compat=21 (or lower). This is yet another attempt to land vector deleting destructors support originally implemented by https://github.com/llvm/llvm-project/pull/133451. This PR contains fixes for issues reported in the original PR as well as fixes for issues related to operator delete[] search reported in several issues like https://github.com/llvm/llvm-project/pull/133950#issuecomment-2787510484 https://github.com/llvm/llvm-project/issues/134265 Fixes https://github.com/llvm/llvm-project/issues/19772
Found it while looking at other stuffs.
This rename was made as part of https://github.com/llvm/llvm-project/pull/147835 in order to ease rebasing the PR, and give a nice window for other patches to get rebased as well. It has been a while already, so lets go ahead and rename it back.
In 765d8a192180f8f33618087b15c022fe758044af we impelemented a fix for incorrect deletion of default constructors in unions. This fix missed a case and so this PR will extend the fix to cover the additional case. Fixes: https://github.com/llvm/llvm-project/issues/81774
In the standard, constraint satisfaction checking is done on the normalized form of a constraint. Clang instead substitutes on the non-normalized form, which causes us to report substitution failures in template arguments or concept ids, which is non-conforming but unavoidable without a parameter mapping This patch normalizes before satisfaction checking. However, we preserve concept-id nodes in the normalized form, solely for diagnostics purposes. This addresses https://github.com/llvm/llvm-project/issues/61811 and related concepts conformance bugs, ideally to make the remaining implementation of concept template parameters easier Fixes https://github.com/llvm/llvm-project/issues/135190 Fixes https://github.com/llvm/llvm-project/issues/61811 Co-authored-by: Younan Zhang [zyn7109@gmail.com](mailto:zyn7109@gmail.com) --------- Co-authored-by: Younan Zhang <zyn7109@gmail.com>
Crash report came in and it was pretty obvious the diagnostic line was just missing an argument. I supplied the argument and added a test. Fixes: https://github.com/llvm/llvm-project/issues/161072
Reverts llvm/llvm-project#141776 CI failures https://lab.llvm.org/buildbot/#/builders/202/builds/3591 https://lab.llvm.org/buildbot/#/builders/55/builds/18066 https://lab.llvm.org/buildbot/#/builders/85/builds/14103
In the standard, constraint satisfaction checking is done on the normalized form of a constraint. Clang instead substitutes on the non-normalized form, which causes us to report substitution failures in template arguments or concept ids, which is non-conforming but unavoidable without a parameter mapping This patch normalizes before satisfaction checking. However, we preserve concept-id nodes in the normalized form, solely for diagnostics purposes. This addresses #61811 and related concepts conformance bugs, ideally to make the remaining implementation of concept template parameters easier Fixes #135190 Fixes #61811 Co-authored-by: Younan Zhang <zyn7109@gmail.com>
This implements the easy parts of P2686R5. Ie allowing constexpr structured binding of structs and arrays. References to constexpr variables / support for tuple is left for a future PR. Until we implement the whole thing, the feature is not enabled as an extension in older language modes. Trying to use it as a tuple does produce errors but not meaningful ones. We could add a better diagnostic if we fail to complete the implementation before the end of the clang 22 cycle.