-
Notifications
You must be signed in to change notification settings - Fork 11.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lambda in unevaluated-context is parsed incorrectedly #51641
Comments
This is the link of testing: |
We form a TypeTraitExpr object because we think the trait is dependent, but then we never go and instantiate the static_assert declaration, so we never re-test the type trait expression on instantiation. We think the trait is dependent because we think the expression argument in I think the issue is in Sema::BuildTemplateIdExpr(), which is where the |
@llvm/issue-subscribers-clang-frontend |
/cherry-pick 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)
/branch llvmbot/llvm-project/issue51641 |
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#149 |
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 |
I believe it is safe to backport (I also double-checked with @erichkeane). |
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 is accepted incorrectly by clang while GCC and MSVC++ all spot the failure of assertion. The type of "foo" is obviously NOT "void" at all.
template
void foo(decltype(+{}) lambda, T param);
static_assert(__is_same(decltype(foo), void));
The text was updated successfully, but these errors were encountered: