Regression: Clang crash exit code 139 OR rejects-valid when decltype-ing the result of a templated lambda. #89853
Assignees
Labels
clang:frontend
Language frontend issues, e.g. anything involving "Sema"
crash
Prefer [crash-on-valid] or [crash-on-invalid]
lambda
C++11 lambda expressions
Comments
github-actions
bot
added
the
clang
EugeneZelenko
added
clang:frontend
|
@llvm/issue-subscribers-clang-frontend Author: None (13steinj)
Found on compiler explorer while playing with https://godbolt.org/z/d8a87z3YK.
When the variable is not templated but the lambda is, instead of segfault, appears to be a rejects-valid (determines that a non-lambda is a lambda): https://godbolt.org/z/fa13nn1qE.
Source of boost-ext/mp for the case of asking "what use would such code have": https://github.com/boost-ext/mp/blob/76149014e223a3371895d9b23d9dbd1a05f6af0b/mp.
Compiler explorer currently uses 28cea99 for "trunk". 18.1.0 succeeds. template<auto Pred = []<const char c> {
(void) static_cast<char>(c);
}> // needs to be dependent to take effect
using broken = decltype(Pred.template operator()<'\0'>());
broken<>* boom;Minimal reproduction to get a crash dump: template<typename = void>
static constexpr auto innocuous = []<const char m> {
return m;
};
template<auto Pred = innocuous<>>
using broken = decltype(Pred.template operator()<'\0'>());
broken<>* boom;It happens doing the static cast as well here; I just felt that simply returning was "more minimal." In both cases, making the NTTP const felt "more minimal" but I don't believe it's necessary, in case clang devs feel the opposite. <details> </details> In case it gives a hint, template<auto Pred = []<const char m> {
return m;
}>
using broken = decltype(Pred.template operator()<'\0'>());
broken<>* boom; |
|
Thanks for the report! This is a regression from my recent patch #82310. However, I've come up with a fix and will submit the patch in a moment. |
|
tyvm for the quick response + triage! Also, apologies if my crash dump auto-referenced a slew of GH issues before! Something with the way GH parses markdown made it so that without a blank line it wasn't treated as a code-block. I edited to add the line but don't know if references get removed if edited. |
zyn0217
added a commit
that referenced
this issue
Aug 27, 2024
…late decl (#89934) In the last patch #82310, we used template depths to tell if such alias decls contain lambdas, which is wrong because the lambda can also appear as a part of the default argument, and that would make `getTemplateInstantiationArgs` provide extra template arguments in undesired contexts. This leads to issue #89853. Moreover, our approach for #82104 was sadly wrong. We tried to teach `DeduceReturnType` to consider alias template arguments; however, giving these arguments in the context where they should have been substituted in a `TransformCallExpr` call is never correct. This patch addresses such problems by using a `RecursiveASTVisitor` to check if the lambda is contained by an alias `Decl`, as well as twiddling the lambda dependencies - we should also build a dependent lambda expression if the surrounding alias template arguments were dependent. Fixes #89853 Fixes #102760 Fixes #105885
llvmbot
pushed a commit
to llvmbot/llvm-project
that referenced
this issue
Aug 27, 2024
…late decl (llvm#89934) In the last patch llvm#82310, we used template depths to tell if such alias decls contain lambdas, which is wrong because the lambda can also appear as a part of the default argument, and that would make `getTemplateInstantiationArgs` provide extra template arguments in undesired contexts. This leads to issue llvm#89853. Moreover, our approach for llvm#82104 was sadly wrong. We tried to teach `DeduceReturnType` to consider alias template arguments; however, giving these arguments in the context where they should have been substituted in a `TransformCallExpr` call is never correct. This patch addresses such problems by using a `RecursiveASTVisitor` to check if the lambda is contained by an alias `Decl`, as well as twiddling the lambda dependencies - we should also build a dependent lambda expression if the surrounding alias template arguments were dependent. Fixes llvm#89853 Fixes llvm#102760 Fixes llvm#105885 (cherry picked from commit b412ec5)
5c4lar
pushed a commit
to 5c4lar/llvm-project
that referenced
this issue
Aug 29, 2024
…late decl (llvm#89934) In the last patch llvm#82310, we used template depths to tell if such alias decls contain lambdas, which is wrong because the lambda can also appear as a part of the default argument, and that would make `getTemplateInstantiationArgs` provide extra template arguments in undesired contexts. This leads to issue llvm#89853. Moreover, our approach for llvm#82104 was sadly wrong. We tried to teach `DeduceReturnType` to consider alias template arguments; however, giving these arguments in the context where they should have been substituted in a `TransformCallExpr` call is never correct. This patch addresses such problems by using a `RecursiveASTVisitor` to check if the lambda is contained by an alias `Decl`, as well as twiddling the lambda dependencies - we should also build a dependent lambda expression if the surrounding alias template arguments were dependent. Fixes llvm#89853 Fixes llvm#102760 Fixes llvm#105885
tru
pushed a commit
to llvmbot/llvm-project
that referenced
this issue
Sep 1, 2024
…late decl (llvm#89934) In the last patch llvm#82310, we used template depths to tell if such alias decls contain lambdas, which is wrong because the lambda can also appear as a part of the default argument, and that would make `getTemplateInstantiationArgs` provide extra template arguments in undesired contexts. This leads to issue llvm#89853. Moreover, our approach for llvm#82104 was sadly wrong. We tried to teach `DeduceReturnType` to consider alias template arguments; however, giving these arguments in the context where they should have been substituted in a `TransformCallExpr` call is never correct. This patch addresses such problems by using a `RecursiveASTVisitor` to check if the lambda is contained by an alias `Decl`, as well as twiddling the lambda dependencies - we should also build a dependent lambda expression if the surrounding alias template arguments were dependent. Fixes llvm#89853 Fixes llvm#102760 Fixes llvm#105885 (cherry picked from commit b412ec5)
dmpolukhin
pushed a commit
to dmpolukhin/llvm-project
that referenced
this issue
Sep 2, 2024
…late decl (llvm#89934) In the last patch llvm#82310, we used template depths to tell if such alias decls contain lambdas, which is wrong because the lambda can also appear as a part of the default argument, and that would make `getTemplateInstantiationArgs` provide extra template arguments in undesired contexts. This leads to issue llvm#89853. Moreover, our approach for llvm#82104 was sadly wrong. We tried to teach `DeduceReturnType` to consider alias template arguments; however, giving these arguments in the context where they should have been substituted in a `TransformCallExpr` call is never correct. This patch addresses such problems by using a `RecursiveASTVisitor` to check if the lambda is contained by an alias `Decl`, as well as twiddling the lambda dependencies - we should also build a dependent lambda expression if the surrounding alias template arguments were dependent. Fixes llvm#89853 Fixes llvm#102760 Fixes llvm#105885
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Found on compiler explorer while playing with https://godbolt.org/z/d8a87z3YK.
When the variable is not templated but the lambda is, instead of segfault, appears to be a rejects-valid (determines that a non-lambda is a lambda): https://godbolt.org/z/fa13nn1qE.
Source of boost-ext/mp for the case of asking "what use would such code have": https://github.com/boost-ext/mp/blob/76149014e223a3371895d9b23d9dbd1a05f6af0b/mp.
Compiler explorer currently uses 28cea99 for "trunk". 18.1.0 succeeds.
Minimal reproduction to get a rejects-valid (seemingly confusing the type of the NTTP in the lambda to be the type of the lambda itself)?
Minimal reproduction to get a crash dump:
It happens doing the static cast as well here; I just felt that simply returning was "more minimal." In both cases, making the NTTP const felt "more minimal" but I don't believe it's necessary, in case clang devs feel the opposite.
Crash Dump
In case it gives a hint,
-Wunused-variable(no crash, no rejects valid) in this variation in "trunk" but not 18.1.0:The text was updated successfully, but these errors were encountered: