See the following link for details

http://www.arjanknepper.com/drupal/?q=node/4

Arjan wrote:
> See the following link for details
> 
> http://www.arjanknepper.com/drupal/?q=node/4

Thanks for doing this, I had a go at the 688 error and got:

namespace newline {
const int posix = 1;
}

class newline_filter {
    void foo()
    {
        int x = newline::posix;
    }

    int newline()
    {
    }
};

Could you add which tests that the files are from? These files are very big (too big for my normal windows text editor). I've found a good approach is to start with the test file and reduce that to make it as simple as possible, and then remove as many headers as possible, which tends to make the generated code a lot smaller.

Daniel James wrote:
> Thanks for doing this, I had a go at the 688 error and got:
> 
> namespace newline {
> const int posix = 1;
> }
> 
> class newline_filter {
>     void foo()
>     {
>         int x = newline::posix;
>     }
> 
>     int newline()
>     {
>     }
> };

The source code is incorrect, but of course the compiler should give the right message instead of an internal error.

Daniel James wrote:
> Arjan wrote:
>> See the following link for details
>>
>> http://www.arjanknepper.com/drupal/?q=node/4
> 
> Thanks for doing this, I had a go at the 688 error and got:
> 
> namespace newline {
> const int posix = 1;
> }
> 
> class newline_filter {
>     void foo()
>     {
>         int x = newline::posix;
>     }
> 
>     int newline()
>     {
>     }
> };
> 
> Could you add which tests that the files are from? 

I will add that information to the page.

These files are very
> big (too big for my normal windows text editor). I've found a good approach is to start with the test file and reduce that to make it as simple as possible, and then remove as many headers as possible, which tends to make the generated code a lot smaller.

That is a good tip!

At first I try to locate the offending statement(s) / code-
block in the original code. Sometimes its possible to create a simple sample direct from that piece of code.

When the above approach fails, I fall back to the "-e -l" method. The samples on the page are all produced by "-e -l".

Arjan

Walter Bright wrote:
> Daniel James wrote:
>> Thanks for doing this, I had a go at the 688 error and got:
>>
>> namespace newline {
>> const int posix = 1;
>> }
>>
>> class newline_filter {
>>     void foo()
>>     {
>>         int x = newline::posix;
>>     }
>>
>>     int newline()
>>     {
>>     }
>> };
> 
> The source code is incorrect, but of course the compiler should give the right message instead of an internal error.

That's what I thought at first, but it's actually valid. From 3.4.3:

> During the lookup for a name preceding the :: scope resolution
> operator, object, function, and enumerator names are ignored.

Although, Boost generally avoids writing code like this, as several compilers have problems. It comes from a test, not the library implementation.

Daniel James wrote:
> Walter Bright wrote:
>> Daniel James wrote:
>>> Thanks for doing this, I had a go at the 688 error and got:
>>>
>>> namespace newline {
>>> const int posix = 1;
>>> }
>>>
>>> class newline_filter {
>>>     void foo()
>>>     {
>>>         int x = newline::posix;
>>>     }
>>>
>>>     int newline()
>>>     {
>>>     }
>>> };
>>
>> The source code is incorrect, but of course the compiler should give the right message instead of an internal error.
> 
> That's what I thought at first, but it's actually valid. From 3.4.3:
> 
>  > During the lookup for a name preceding the :: scope resolution
>  > operator, object, function, and enumerator names are ignored.
> 
> Although, Boost generally avoids writing code like this, as several compilers have problems. It comes from a test, not the library implementation.

Thanks, I understand now. I think I have it fixed. I don't understand, however, what the rationale might be for this lookup rule. It makes for unnecessary complexity (not just for the compiler, for anyone trying to understand the code).

Arjan wrote:
> See the following link for details
> 
> http://www.arjanknepper.com/drupal/?q=node/4

Pavel mentioned the 1848 ICE ice1848.cpp (libs/type_traits/test/is_abstract_test.cpp) elsewhere, and like he said, it does seem to be caused by the size of the tests. The test file contains this:

     #if !(defined(BOOST_MSVC) && (BOOST_MSVC < 1310))
     // MSVC prior to VC7.1 always runs out of swap space trying to
     // compile these, so leave them out for now (the test fails anyway).

Set the preprocessor command to '#if 0' and the ICE goes away (I wasn't able to check if the test passes or fails as there's something wrong with my setup).

I managed to reduce the 2147 ICE (libs/lambda/test/switch_construct.cpp) to the attached file. It could probably be reduced further, but I've got other things to be getting on with right now. I'm pretty sure the ICE happens when instantiating the lambda call (ie. the call to func() in foo), and has something to do with the complexity of the call. It doesn't occur if some of the variable names (eg. if n_action is made any shorter) are made a little shorter which perhaps gives a clue to what's going wrong.