[cfe-dev] Crash in CallExpr::getCallReturnType

[Gábor Márton via cfe-dev]

Hi Balázs,

I think it is normal to give a Null type in this case:
The CallExpr refers to an overloaded function and that is not resolved yet,
because the overload resolution has not happened yet at this point.

However, this could happen only if the enclosing class template (the
generic lambda) is not yet instantiated. But I'd expect that the lambda
class template is instantiated since for_each is instantiated with a
concrete type (the iterator of std::vector<unsigned char>). Could you
please check if the lambda class template is instantiated?

Gabor

On Wed, Jan 20, 2021 at 4:43 PM Balázs Kéri via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi!
> I encountered a case when function CallExpr::getCallReturnType is called
> and crashes because a null type pointer. Should this function return a
> value in any case and not crash?
>
>  #0 0x00007f8cbb81baef llvm::sys::PrintStackTrace(llvm::raw_ostream&)
> llvm/lib/Support/Unix/Signals.inc:564:0
>  #1 0x00007f8cbb81bb82 PrintStackTraceSignalHandler(void*)
> llvm/lib/Support/Unix/Signals.inc:625:0
>  #2 0x00007f8cbb81991d llvm::sys::RunSignalHandlers()
> llvm/lib/Support/Signals.cpp:68:0
>  #3 0x00007f8cbb81b32e llvm::sys::CleanupOnSignal(unsigned long)
> llvm/lib/Support/Unix/Signals.inc:361:0
>  #4 0x00007f8cbb69074a (anonymous
> namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long)
> llvm/lib/Support/CrashRecoveryContext.cpp:77:0
>  #5 0x00007f8cbb690c22 CrashRecoverySignalHandler(int)
> llvm/lib/Support/CrashRecoveryContext.cpp:383:0
>  #6 0x00007f8cbacce040 (/lib/x86_64-linux-gnu/libc.so.6+0x3f040)
>  #7 0x00007f8cbaccdfb7 raise
> /build/glibc-S9d2JN/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
>  #8 0x00007f8cbaccf921 abort
> /build/glibc-S9d2JN/glibc-2.27/stdlib/abort.c:81:0
>  #9 0x00007f8cbacbf48a __assert_fail_base
> /build/glibc-S9d2JN/glibc-2.27/assert/assert.c:89:0
> #10 0x00007f8cbacbf502 (/lib/x86_64-linux-gnu/libc.so.6+0x30502)
> #11 0x00007f8cc4e8fdd2 clang::FunctionType const*
> clang::Type::castAs<clang::FunctionType>() const
> clang/include/clang/AST/Type.h:7060:0
> #12 0x00007f8cb533b3e9
> clang::CallExpr::getCallReturnType(clang::ASTContext const&) const
> clang/lib/AST/Expr.cpp:1453:0
>
> The following AST node (CallExpr, for function "to_string") causes the
> problem:
>               `-CompoundStmt <col:81, line:9:3>
>                 `-CallExpr <line:8:5, col:27> '<dependent type>'
>                   |-UnresolvedLookupExpr <col:5, col:10> '<overloaded
> function type>' lvalue (no ADL) = 'to_string' 0x562191753998 0x562191755ac8
> 0x562191756418 0x562191756d68 0x5621917576b8 0x562191758008 0x5621917599a8
> 0x56219175c928 0x56219175f888
>                   `-DeclRefExpr <col:20> 'const auto' lvalue ParmVar
> 0x56219197d868 'element' 'const auto &'
>
> This is the source code:
>
> #include <algorithm>
> #include <string>
> #include <vector>
>
> void f() {
>   const std::vector<unsigned char> buffer;
>   std::for_each(std::cbegin(buffer), std::cend(buffer), [](const auto&
> element) {
>     std::to_string(element);
>   });
> }
>
> ---
> Balázs
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210121/9b318040/attachment.html>