Why does VC++ 2010 compiler crash when compiling simple code?

Question

I encountered a very strange symptom. Who can tell me what the root cause is?

My VC++ compiler version is latest: "Microsoft Visual C++ 2010 : 01019-532-2002102-70860"

Steps to reproduce:

1. Create an empty win32 console project
2. Add a new cpp file named main.cpp
3. Paste the following code into main.cpp
4. Compile
5. The compiler crashes and reports the following message:

\bug\main.cpp(54893757): fatal error C1001: An internal error has occurred in the compiler. (compiler file 'msc1.cpp', line 1420)

To work around this problem, try simplifying or changing the program near the locations listed above. Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information.

This error occurred in injected text:

d:\bug\main.cpp(63) : see reference to function template instantiation 'XDummy Test(T)' being compiled with [ T=int ]

Build FAILED.

Below is the source code of main.cpp:

#include <vector> 

template<class It_> 
struct trait_dummy 
{ 
    static const int value = std::tr1::is_convertible<typename iterator_traits<It_>::iterator_category, int>::value;     
}; 

template<class It_> 
class X 
{ 
public: 
    template<class T_> 
    X(T_& rColl) 
    {} 
}; 

template<class T_> 
X<typename T_::iterator> f(T_ rColl, std::false_type) 
{ 
    return X<typename T_::iterator>(rColl); 
} 

template<class T_> 
auto f(T_& rColl) -> decltype(f(rColl, std::false_type())) 
{ 
    return f(rColl, std::false_type()); 
} 

template<class It_> 
X<It_> f(It_ first, size_t nSize, typename std::tr1::enable_if<trait_dummy<It_>::value>::type* dummy = 0) 
{ 
    return X<It_>(first, first + nSize); 
} 

class XTest 
{ 
public: 
    void foo() 
    { 
        auto v = f(m_Suite); 
    }    

    std::vector<int> m_Suite; 
}; 

const int g_dummy = 0; 
class XDummy 
{ 
public: 
    XDummy(int, int, int, int dummy = g_dummy) 
    {} 
}; 

template<class T> 
XDummy Test(T) 
{    
    return XDummy(0, 0, 0); 
} 

int main() 
{ 
    Test(0); 
    //XTest().foo(); 

    return 0; 
}

Shavers

If you can reduce your code to the minimum code that causes the internal compiler error, please consider submitting a bug report at Microsoft Connect. – Community

Using the auto keyword like that seems bad/lazy. I don't want to have to dig through multiple function call layers to find out what type a function returns. And if the return type of an inner function changes, I'd rather get compiler errors at the point the changed function was called rather than two layers up, wondering what happened and having to search for the cause of the knock-on change(s)... Using auto is handy when defining local iterator variables but using it in function signatures seems like a bad idea. – Lobster

@Leo Davidson: I don't like auto + decltype too. However, in many cases, auto + decltype is indispensable. If not necessary, I will not use them to define a function. – Shavers

Apologies, I didn't notice the "->" stuff going on on the same line! Auto is probably entirely justified there. – Lobster

@Tomalak, be glad the c++ community advances as template are categorized as 'basic' :) – Gape

Answer 1

Have you tried any type of troubleshooting yourself?

I can reproduce the crash using the above source code as you describe. Of course, I get a couple of warnings:

• "IntelliSense: no instance of overloaded function "f" matches the argument list"
• "IntelliSense: too few arguments in function call"

both referring to this line:

auto v = f(m_Suite); 

A few more seconds of troubleshooting discovers that by commenting out the entire XTest class, the code compiles and executes without a problem (and most importantly, without crashing the compiler). That tells me (and should tell you) that the problem clearly lies somewhere within the XTest class.
You can't help but wonder if that has something to do with the compiler errors that are being generated.

Well, how about if we just comment out that single line that's producing the compiler errors? What do you know! The code compiles and executes just fine!

So in under about a minute, we've narrowed down the culprit to a single line of code. I'm not going to actually take the time to understand exactly what all of your code does, though, since I think you can take it from here now that you know exactly where to concentrate your efforts. Start by fixing those IntelliSense errors and see if your code compiles without crashing the compiler.

Phytogeography

Note that the "IntelliSense..." errors are not really compiler errors as they are generated by IntelliSense, not the compiler. The Visual C++ Compiler and IntelliSense use completely different frontends, so often one may report an error while the other may not. – Community

IMO funny thing about invalid code crashing compiler is not that the code is invalid, but that it crashes compiler :) – Muse

@James McNellis: You're right that they're not strictly compiler errors, but the warnings seem to me to indicate something might be wrong with that line of code, and from my tests, that's the case. That should at least make them worth some attention, given the circumstances. – Phytogeography

And either way, getting the code down to the bare minimum necessary to reproduce the compiler error/crash makes the question much easier to read and answer at a glance. – Phytogeography

@Piotr Findeisen: What you said is just what want to say. – Shavers

@Piotr, @xmllmx: I suppose you're right. I didn't consider that, and in that case, you propose an interesting question. Something we get wrapped up in trying to fix the problem that we fail to notice the bigger picture. :-) – Phytogeography

@Cody Gray: The code above has been minimized to make it smallest to understand. – Shavers

Another big picture is that a compiler gets tested against a very large suite of valid source code that tests every nook and cranny of the language. But no test suite can every claim that it tests all possible invalid code. – Cashbox

I find that intellisense is generally pissed off at me forever. Even with the vast improvements made in 2010 over previous versions, stupisence seems like a more descriptive title. – Homothallic

Answer 2

Compiler authors don't put a very high priority into fixing bugs in their compiler that don't affect the compiler's ability to generate valid output from valid input. And among those bugs, the very lowest priority goes to those bugs that don't silently produce invalid output.

So the answer to your question is that most likely it's either because this bug hasn't been previously reported or has been assigned a very, very low priority.

Rede

I've seen these kind of problems pop up. For example code that compiles fine with VS2013 gives the "internal (compiler file 'msc1.cpp', line 1420)" fail when used with VS2010. Anyway the culprit will be the usage of decltype it's almost always the reason I see this error with VS2010 – Nassir