Closed JMLX42 closed 10 years ago
That is probably the strangest thing I've seen in a while.
Any update on this?
I really have no idea what is going on there. Is it still crashing MSVC? even with the latest master?
We have solved alsmot all VS2013 compiler issues. All but one, and it's a big one. Apparently, VS2013 compiler (even the latest Nov 2013 CTP one) crashes when using LuaGlueClass::method() by passing a pointer to a static method that takes no arguments.
class Vector3
{
// ...
static
Ptr
zero()
{
return create(0.f, 0.f, 0.f);
}
}
The following line will cause a compiler crash:
state.Class<Vector3>("Vector3").method("zero", &Vector3::zero);
7>c:\projects\minko-cpp\plugins\lua\src\minko\math\luavector3.hpp(46): fatal error C1001: An internal error has occurred in the compiler. 7> (compiler file 'msc1.cpp', line 1358) 7> To work around this problem, try simplifying or changing the program near the locations listed above. 7> Please choose the Technical Support command on the Visual C++ 7> Help menu, or open the Technical Support help file for more information 7> INTERNAL COMPILER ERROR in 'C:\Program Files (x86)\Microsoft Visual C++ Compiler Nov 2013 CTP\bin\CL.exe' 7> Please choose the Technical Support command on the Visual C++ 7> Help menu, or open the Technical Support help file for more information
It seams to match this bugs:
Suprisingly, the crash occurs "mostly" on Windows 8. We don't know why it "appears" to "work" on Windows 7 but it definitely fails on Windows 8 (same IDE, same compiler) and it is definitely related to the fact that this static method has no argument: declaring a phony argument makes it work flawlessly on all configurations.
When dealing with such method pointers outside of LuaGlue, the compiler works perfectly (hopefully...). So is there anything in LuaGlue that could confuse the compiler as far as those method pointers are concerned?
Regards,
I just commented this code:
//template
Then, I replaced tuple<_Args...> args; by std::tuple<_Args...> args;
This fix helped. My code successfully compiled and example foo.lua works perfect!
Don't forget we're dealing with headers here. It will "compile" and "work" as long as you don't do use const or references, which was exactly the point of using our own tuple typedef based on std::remove_const and std::remove_reference.
So this is not a viable fix because you'll likely need to bind C++ stuff that deals with references and constness.
I just found the real problem which is an actual bug in the VS compiler. Looks like my recent additions to "decorate" C++ methods causes an ambiguous overloads on the LuaGlueClass::method method and VS crash trying to solve it.
The solution is to rename those wrapping LuaGlueClass::method overloads into LuaGlueClass::methdWrapper. The problematic overloads are the one that expects a _Class* or std::shared_ptr<_Class> as a first argument. So this:
template<typename _Ret, typename... _Args>
LuaGlueClass<_Class> &method(const std::string &name, _Ret(*fn)(_Class*, _Args...))
{
//printf("decorator method(%s)\n", name.c_str());
auto impl = new LuaGlueStaticMethod<_Ret, _Class, _Class*, _Args...>(this, name, std::forward<decltype(fn)>(fn));
methods.addSymbol(name.c_str(), impl);
return *this;
}
template<typename _Ret, typename... _Args>
LuaGlueClass<_Class> &method(const std::string &name, _Ret(*fn)(std::shared_ptr<_Class>, _Args...))
{
//printf("decorator method(%s)\n", name.c_str());
auto impl = new LuaGlueStaticMethod<_Ret, _Class, std::shared_ptr<_Class>, _Args...>(this, name, std::forward<decltype(fn)>(fn));
methods.addSymbol(name.c_str(), impl);
return *this;
}
becomes this:
template<typename _Ret, typename... _Args>
LuaGlueClass<_Class> &methodWrapper(const std::string &name, _Ret(*fn)(_Class*, _Args...))
{
//printf("decorator method(%s)\n", name.c_str());
auto impl = new LuaGlueStaticMethod<_Ret, _Class, _Class*, _Args...>(this, name, std::forward<decltype(fn)>(fn));
methods.addSymbol(name.c_str(), impl);
return *this;
}
template<typename _Ret, typename... _Args>
LuaGlueClass<_Class> &methodWrapper(const std::string &name, _Ret(*fn)(std::shared_ptr<_Class>, _Args...))
{
//printf("decorator method(%s)\n", name.c_str());
auto impl = new LuaGlueStaticMethod<_Ret, _Class, std::shared_ptr<_Class>, _Args...>(this, name, std::forward<decltype(fn)>(fn));
methods.addSymbol(name.c_str(), impl);
return *this;
}
So to wrap/decorate a C++ method we would now have to use LuaGlueClass::methodWrapper instead of LuaGlueClass::method, which is not a big change and is much more meaningful I thing.
I also replaced the template aliases with typedef and it helped.
I tested it on VS2013 on Windows 7 and 8 and it works great. I'll try to merge upstream and provide a pull request ASAIC.
Regards,
promethe42, thx for this solution. But when i fixing LuaGlueClass.h as your example, renaming two methods, my compiler now return error.
What errors?
1>c:\program files (x86)\microsoft visual studio 12.0\vc\include\luaglue\luagluemethod.h(116): fatal error C1001: An internal error has occurred in the compiler. 1> (compiler file 'f:\dd\vctools\compiler\cxxfe\sl\p1\c\template.cpp', line 12097)
Or
1>c:\program files (x86)\microsoft visual studio 12.0\vc\include\luaglue\luagluemethod.h(24): fatal error C1001: An internal error has occurred in the compiler. 1> (compiler file 'msc1.cpp', line 1358)
with newest november2013 msvc compiler:
You should replace of template aliases ("using ....") with typedefs.
On Fri, Feb 7, 2014 at 1:53 PM, killtuzarr notifications@github.com wrote:
Or
1>c:\program files (x86)\microsoft visual studio 12.0\vc\include\luaglue\luagluemethod.h(24): fatal error C1001: An internal error has occurred in the compiler. 1> (compiler file 'msc1.cpp', line 1358)
with newest november2013 msvc compiler:
— Reply to this email directly or view it on GitHubhttps://github.com/Tomasu/LuaGlue/issues/30#issuecomment-34434035 .
Jean-Marc Le Roux
Founder and CEO of Aerys (http://aerys.in)
Blog: http://blogs.aerys.in/jeanmarc-leroux Cell: (+33)6 20 56 45 78 Phone: (+33)9 72 40 17 58
Sorry, but i can't replace this template aliases:
template <typename... T>
using tuple = std::tuple<typename std::remove_const<typename std::remove_reference<T>::type>::type...>;
with typedefs, my example:
template <typename... T>
typedef std::tuple<typename std::remove_const<typename std::remove_reference<T>::type>::type...> mytuple;
Yes you can:
typedef std::tuple<typename std::remove_const<typename std::remove_reference<_Args>::type>::type...> ArgsTuple;
and then:
ArgsTuple arguments;
Many thanks for the provided example. Now it works perfectly. Best regards!!!
I really appreciate you guys looking into this! Looking forward to the patch.
Was there a patch for this coming? Can I assume this is what's causing the crash in #46
Is this still a problem? If so, please reopen.
I'm working on a completely unrelated project, but it uses variadic templates and has a very similar looking error down to the template.cpp reference (different line #) and all the warnings about reserved macro names. The project builds fine on my Windows 7 desktop with VS 2013 Update 5, but yields the above error on Windows 2012 R2 with VS 2013 Update 3. We're going to apply VS 2013 Update 5 and hope that resolves the error. Update installed -- it does resolve the problem.
Hello,
after applying the fix described in #26 for LG_DEBUG under Windows 7 64 bits VS 2013 Ultimate, the compiler actually crashes: