out of line definition should reject template parameter with lambda of unevaluated context #51416
Comments
EugeneZelenko
added
the
clang:frontend
|
@llvm/issue-subscribers-clang-frontend |
|
/cherry-pick 3784e8c |
|
/branch llvmbot/llvm-project/issue51416 |
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 llvm#50376 Fixes llvm#51414 Fixes llvm#51416 Fixes llvm#51641 Fixes llvm#54296 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D121532 (cherry picked from commit 3784e8c)
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 llvm#50376 Fixes llvm#51414 Fixes llvm#51416 Fixes llvm#51641 Fixes llvm#54296 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D121532 (cherry picked from commit 3784e8c)
|
/pull-request llvmbot#148 |
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 llvm#50376 Fixes llvm#51414 Fixes llvm#51416 Fixes llvm#51641 Fixes llvm#54296 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D121532 (cherry picked from commit 3784e8c)
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 llvm#50376 Fixes llvm#51414 Fixes llvm#51416 Fixes llvm#51641 Fixes llvm#54296 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D121532 (cherry picked from commit 3784e8c)
|
@AaronBallman Is this safe to backport? 3784e8c |
Yes, I think it is (I also double-checked with @erichkeane). |
|
@cor3ntin We can't merge the patch as is, because there are ABI breaking changes to CreateLambda() and createLambdaClosureType(). Is there someway to rework the patch without changing the ABI? |
|
@tstellar That seems pretty difficult if not impossible. I guess if we can't backport this, we might need to consider reverting https://reviews.llvm.org/rG22aa3680eaccb9b77ca224711c4da3a354aa2d45 in the 14x branche instead, would that be possible? The state of affair in the 14 branch is pretty sad, as it crashes on very simple and non unusual code, like What would be the process for that? |
|
Oof, I didn't spot the ABI break, that is unfortunate. (Good catch @tstellar!). We could do something like this: https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaDeclCXX.cpp#L7013 to differ the ABI based on what the user wants to be compatible with, but that may be a risky approach this late (or maybe it actually turns out to be straightforward, I don't know). |
|
@AaronBallman I'm just talking about the ABI of libclang-cpp.so. Is there also an ABI issue with the code that the complier generates with this patch? |
|
@cor3ntin I think you can fix it by adding an overload of createLambdaClosureType() with the old parameter types and have that wrap the new implementation. |
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 llvm/llvm-project#50376 Fixes llvm/llvm-project#51414 Fixes llvm/llvm-project#51416 Fixes llvm/llvm-project#51641 Fixes llvm/llvm-project#54296 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D121532
Extended Description
The following code should be rejected as no matching declaration found as GCC/MSVC++ does. clang-13 incorrectly passes without considering that two lambda expressions are never considered as equivalent. [temp.over.link#5.sentence-4]
template
struct A{
void spam(decltype([]{}) );
};
template
void A::spam(decltype([]{}))
{}
struct A{
template
void spam(decltype([]{}) );
};
template
void A::spam(decltype([]{}))
{}
Both of above should be rejected as no declaration found.
The text was updated successfully, but these errors were encountered: