FunctionDecl::getParamDecl: Assertion i < getNumParams() && "Illegal param #" failed
#102760
Assignees
Labels
c++20
clang:frontend
Language frontend issues, e.g. anything involving "Sema"
confirmed
Verified by a second party
crash
Prefer [crash-on-valid] or [crash-on-invalid]
regression:19
Regression in 19 release
Comments
Endilll
added
c++20
clang:frontend
|
@llvm/issue-subscribers-clang-frontend Author: Vlad Serebrennikov (Endilll)
While reducing #77250, I stumbled upon the following assertion (https://godbolt.org/z/s77h5PEKv):
```cpp
auto __make_tuple = []< class _Tag, class... _Captures >(_Tag, _Captures...) {
return []< class _Fun >( _Fun) -> void
requires requires { 0; }
{};
};
template < class, class... _As > using T = __call_result_t< int, int >; clang++: /root/llvm-project/clang/include/clang/AST/Decl.h:2674: clang::ParmVarDecl* clang::FunctionDecl::getParamDecl(unsigned int): Assertion `i < getNumParams() && "Illegal param #"' failed.
|
|
@llvm/issue-subscribers-c-20 Author: Vlad Serebrennikov (Endilll)
While reducing #77250, I stumbled upon the following assertion (https://godbolt.org/z/s77h5PEKv):
```cpp
auto __make_tuple = []< class _Tag, class... _Captures >(_Tag, _Captures...) {
return []< class _Fun >( _Fun) -> void
requires requires { 0; }
{};
};
template < class, class... _As > using T = __call_result_t< int, int >; clang++: /root/llvm-project/clang/include/clang/AST/Decl.h:2674: clang::ParmVarDecl* clang::FunctionDecl::getParamDecl(unsigned int): Assertion `i < getNumParams() && "Illegal param #"' failed.
|
Endilll
changed the title
FunctionDecl::getParamDecl: Assertion i < getNumParams() && "Illegal param #"' failed`FunctionDecl::getParamDecl: Assertion 'i < getNumParams() && "Illegal param #"' failed
Endilll
changed the title
FunctionDecl::getParamDecl: Assertion 'i < getNumParams() && "Illegal param #"' failedFunctionDecl::getParamDecl: Assertion i < getNumParams() && "Illegal param #" failed
|
Looks like a regression from clang-18: https://godbolt.org/z/TWhdfzvc3 |
|
@AaronBallman if there is an rc4, we should keep an eyes on this one |
|
Sorry for replying late. EDIT: I mean, 19. |
|
#89934 might be small enough to backport - major refactor of lambdas is strictly for clang 20+ |
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)
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)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While reducing #77250, I stumbled upon the following assertion (https://godbolt.org/z/s77h5PEKv):
Clang 20.0 crash:
The text was updated successfully, but these errors were encountered: