-
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
Clang C++20 Feature: P0315R4 - Lambdas in unevaluated contexts #54296
Labels
Comments
@llvm/issue-subscribers-c-20 |
Can we rename issue-subscribers-c-20 to issue-subscribers-cpp-20 (or something like that) to avoid confusion? |
@ecnelises: Please file new issue for that. |
This is marked partial because |
EugeneZelenko
added
the
clang:frontend
Language frontend issues, e.g. anything involving "Sema"
label
Mar 25, 2022
@llvm/issue-subscribers-clang-frontend |
cor3ntin
added a commit
that referenced
this issue
Mar 25, 2022
llvmbot
pushed a commit
to llvmbot/llvm-project
that referenced
this issue
Apr 2, 2022
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)
llvmbot
pushed a commit
to llvmbot/llvm-project
that referenced
this issue
Apr 2, 2022
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)
llvmbot
pushed a commit
to llvmbot/llvm-project
that referenced
this issue
Apr 2, 2022
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)
llvmbot
pushed a commit
to llvmbot/llvm-project
that referenced
this issue
Apr 2, 2022
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)
mem-frob
pushed a commit
to draperlaboratory/hope-llvm-project
that referenced
this issue
Oct 7, 2022
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
mem-frob
pushed a commit
to draperlaboratory/hope-llvm-project
that referenced
this issue
Oct 7, 2022
The documentation contained extra space. Also remove llvm/llvm-project#54296 from the list of issues by 3784e8cc as this commit did not fix it (nor was it supposed to).
This is now fully implemented (in clang 17) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
id: P0315R4
paper: https://wg21.link/p0315r4
partially implemented: status unknown
The text was updated successfully, but these errors were encountered: