Crash on using local struct in function template as template parameter

[llvmbot]

Bugzilla Link	9685
Resolution	FIXED
Resolved on	Dec 11, 2013 18:52
Version	unspecified
OS	All
Attachments	The source responsible for the crash, Clang's crash log
Reporter	LLVM Bugzilla Contributor
CC	@Amanieu,@majnemer,@dwblaikie,@DougGregor,@pogo59,@zygoloid,@rjmccall,@HighCommander4

Extended Description

The attached code crashes clang on compilation. It seems to be a weird combination of

• A class template
• A local struct in the class template's method which in turn contains a
  templated ()-operator and attributes
• An instanciation of the local struct being passed to a template method of
  another class template

I attached the crash log. Clang's version is:

$ /opt/bin/clang -v
clang version 3.0 (trunk 129269)
Target: x86_64-apple-darwin10
Thread model: posix

[llvmbot]

assigned to @majnemer

[dwblaikie]

Are you still seeing this crash? I'm getting the following with r141767 on Ubuntu:

$ clang crash.cpp
crash.cpp:11:23: warning: rvalue references are a C++0x extension [-Wc++0x-extensions]
void forEach(Functor&& functor)
^
crash.cpp:41:14: error: 'Foo::doIt()::Functor::operator()(A *)::Functor::i' is not a member of class 'Foo::Functor'
u->idle(i, f);
^
crash.cpp:13:4: note: in instantiation of function template specialization 'Foo::doIt()::Functor::operator()' requested here
functor(this->value);
^
crash.cpp:51:11: note: in instantiation of function template specialization 'Tuple::forEach<Foo::Functor>' requested here
this->t.forEach(Functor(0, 1.0f));
^
crash.cpp:69:4: note: in instantiation of member function 'Foo::doIt' requested here
f.doIt();
^
1 warning and 1 error generated.

[llvmbot]

Are you still seeing this crash? I'm getting the following with r141767 on
Ubuntu:

r141771 still results in the same crash here:

$ ~/LLVM/build/Release+Asserts/bin/clang -std=c++0x -v crash.cpp
clang version 3.0 (trunk 141771)
Target: x86_64-apple-darwin10.8.0
Thread model: posix
"/Users/rynnsauer/LLVM/build/Release+Asserts/bin/clang" -cc1 -triple x86_64-apple-macosx10.6.8 -emit-obj -mrelax-all -disable-free -main-file-name crash.cpp -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 97.17 -v -resource-dir /Users/rynnsauer/LLVM/build/Release+Asserts/bin/../lib/clang/3.0 -fmodule-cache-path /var/folders/RI/RI4iqAygH0OWeTzP0+rLU++++TI/-Tmp-/clang-module-cache -std=c++0x -fdeprecated-macro -ferror-limit 19 -fmessage-length 100 -stack-protector 1 -fblocks -fobjc-dispatch-method=mixed -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/RI/RI4iqAygH0OWeTzP0+rLU++++TI/-Tmp-/crash-PPnHTd.o -x c++ crash.cpp
[...]
Assertion failed: (isa(D) && "declaration not instantiated in this scope"), function findInstantiationOf, file /Users/rynnsauer/LLVM/llvm/tools/clang/lib/Sema/SemaTemplateInstantiate.cpp, line 2303.

Strange ...

[dwblaikie]

Are you still seeing this crash? I'm getting the following with r141767 on
Ubuntu:

r141771 still results in the same crash here:

Sorry, my fault, I was using a release build. With a debug build I do see the assertion failure you're seeing. I'll look into it further & see what I can come up with.

[dwblaikie]

Simpler repro source
I've simplified the repro a bit - but I'm uploading it in case others have ideas about how to simplify it further. I'll play around with more simplification myself & see about fixing it soon.

[dwblaikie]

Simpl

[dwblaikie]

Simpler repro source
Further simplified the test.

The essence is any (class or function) template with a local class passed to another template that calls a member function of that local class. This will cause the member function to attempt to be instantiated in the wrong context (the local context of the function that ultimately invokes it, instead of the one it is defined in)

I have a simple 'fix' that Doug has helpfully explained is not really the right approach (& most probably broken, though I haven't created the necessary test cases to demonstrate that, though I believe they exist) though the real fix will certainly need to rework LocalInstantiationScopes substantially.

Some mechanism to track which instantiation scope a local member function corresponds to will be required. Possibly, if the class is instantiated in that scope, we can track it through that (go from the member function, to its enclosing local class and find the relevant scope there). My half-baked patch attempted to just extend the search scope, but that would be insufficient for, at the very least, multiple instances of this problem in the same scope (a function template that instantiates/calls itself with different arguments, then calls something else that uses member functions from instances of the local class from both the instantiations of the outer scope. Each one needs to find the uniquely correct outer scope, not (just) the nearest one, that has the required instantiation)

[dwblaikie]

Oh, and one other thing just so it's written down here:

I suspect this will adversely effect lambda usage quite substantially. Most lambdas are passed to function templates (such as std::for_each, for example) & any use like that where the caller is itself a template, would probably trigger this bug. (depending on the specifics of how lambdas end up being implemented, instantiated, etc - but if they attempt to reuse local class semantics the chances are high the above will occur)

[llvmbot]

Oh, and one other thing just so it's written down here:

I suspect this will adversely effect lambda usage quite substantially. Most
lambdas are passed to function templates (such as std::for_each, for example) &
any use like that where the caller is itself a template, would probably trigger
this bug. (depending on the specifics of how lambdas end up being implemented,
instantiated, etc - but if they attempt to reuse local class semantics the
chances are high the above will occur)

FDIS 5.1.2p3 says:
"The type of the lambda-expression (which is also the type of the closure object) is a unique, unnamed non- union class type — called the closure type — whose properties are described below. This class type is not an aggregate (8.5.1). The closure type is declared in the smallest block scope, class scope, or namespace scope that contains the corresponding lambda-expression."

So I think the Standard mandates that a lambda used inside a function/method is implemented as a local class.

[dwblaikie]

*** Bug llvm/llvm-bugzilla-archive#12702 has been marked as a duplicate of this bug. ***

[pogo59]

+1, I had somebody run into this same problem the other day.

[llvmbot]

Run with optimised clang instead of debug clang showing clang beats gcc

[llvmbot]

Created attachment 9316 [details]
Run with optimised clang instead of debug clang showing clang beats gcc

This comment meant for previous bug, 14026.
Apparently I accidentally hit the next button and didn't notice
when I made comment #​12.

Also, I added the attachment before noticing this mistake also.

Please ignore the comment and attachment.

[zygoloid]

*** Bug llvm/llvm-bugzilla-archive#14374 has been marked as a duplicate of this bug. ***

[zygoloid]

*** Bug llvm/llvm-bugzilla-archive#14373 has been marked as a duplicate of this bug. ***