On 11/29/2015 2:44 AM, Manu via Digitalmars-d wrote:
> Well they took a few hours of my life, and increased my anger level a
> couple of notches.

Per the pull request comments, file bugzilla issues any time such a message appears.

On 11/29/2015 4:36 AM, Jonathan M Davis wrote:
> But there's still really only one symbol that the compiler is dealing with. It's
> kind of like how the C/C++ compiler never really sees macros, though it's more
> controlled than that.

More accurately, like C/C++ typedef behavior.

On 29 November 2015 at 19:51, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 11/29/2015 2:40 AM, Iain Buclaw via Digitalmars-d wrote:
>
>> On 29 Nov 2015 11:30 am, "Jacob Carlborg via Digitalmars-d"
>> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>>  >
>>  > On 2015-11-29 11:19, Iain Buclaw via Digitalmars-d wrote:
>>  >
>>  >> I keep telling them to fix that.  My suggestion of replacing them with
>>  >> meaningful errors was rejected.
>>  >
>>  >
>>  > "rejected", what!! Any assertion in the compiler is a bug. Or was that
>> not
>> from the compiler?
>>  >
>>
>> Someone put in those ICE's on the promise that at some point it would be detected in semantic pass before the symbol mangling was requested.  That promise was never kept.
>>
>> For reference (or if you enjoy time travelling) https://github.com/D-Programming-Language/dmd/pull/4661
>>
>
> I commented there:
>
> "And any test cases that trigger these ICEs should be filed in bugzilla."
>
> What are the bugzilla issues?
>

Many have been reported.

https://issues.dlang.org/show_bug.cgi?id=14537 https://issues.dlang.org/show_bug.cgi?id=14178 https://issues.dlang.org/show_bug.cgi?id=14020 https://issues.dlang.org/show_bug.cgi?id=13870 https://issues.dlang.org/show_bug.cgi?id=13693

On 11/29/2015 1:53 PM, Iain Buclaw via Digitalmars-d wrote:
> Many have been reported.
>
> https://issues.dlang.org/show_bug.cgi?id=14537
> https://issues.dlang.org/show_bug.cgi?id=14178
> https://issues.dlang.org/show_bug.cgi?id=14020
> https://issues.dlang.org/show_bug.cgi?id=13870
> https://issues.dlang.org/show_bug.cgi?id=13693
>
>

Thank you. Reporting bugs is the right solution, not papering over them.

Some of those were misclassified, I fixed them.

On 29 November 2015 at 19:52, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 11/29/2015 2:44 AM, Manu via Digitalmars-d wrote:
>
>> Well they took a few hours of my life, and increased my anger level a couple of notches.
>>
>
> Per the pull request comments, file bugzilla issues any time such a message appears.
>
>
I skip the middle-man and file github pull requests.  It's much nicer to have an issue fixed than reported.  It avoids lengthy mail threads down the line.  :-)

On 29 November 2015 at 23:02, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 11/29/2015 1:53 PM, Iain Buclaw via Digitalmars-d wrote:
>
>> Many have been reported.
>>
>> https://issues.dlang.org/show_bug.cgi?id=14537 https://issues.dlang.org/show_bug.cgi?id=14178 https://issues.dlang.org/show_bug.cgi?id=14020 https://issues.dlang.org/show_bug.cgi?id=13870 https://issues.dlang.org/show_bug.cgi?id=13693
>>
>>
>>
> Thank you. Reporting bugs is the right solution, not papering over them.
>
>
Frankly, I thought things were going well and I was pushing it slowly in the right direction until someone did a rampage over it.  Now I'm back to square one trying to work out what's going on with it, and it's going to need a lot more than papering to recover.

On 30 Nov 2015 7:56 am, "Iain Buclaw via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On 29 November 2015 at 19:51, Walter Bright via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
>>
>> On 11/29/2015 2:40 AM, Iain Buclaw via Digitalmars-d wrote:
>>>
>>> On 29 Nov 2015 11:30 am, "Jacob Carlborg via Digitalmars-d" <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>>
wrote:
>>>  >
>>>  > On 2015-11-29 11:19, Iain Buclaw via Digitalmars-d wrote:
>>>  >
>>>  >> I keep telling them to fix that.  My suggestion of replacing them
with
>>>  >> meaningful errors was rejected.
>>>  >
>>>  >
>>>  > "rejected", what!! Any assertion in the compiler is a bug. Or was
that not
>>> from the compiler?
>>>  >
>>>
>>> Someone put in those ICE's on the promise that at some point it would be detected in semantic pass before the symbol mangling was requested.
That
>>> promise was never kept.
>>>
>>> For reference (or if you enjoy time travelling) https://github.com/D-Programming-Language/dmd/pull/4661
>>
>>
>> I commented there:
>>
>> "And any test cases that trigger these ICEs should be filed in bugzilla."
>>
>> What are the bugzilla issues?
>
>
> Many have been reported.
>
> https://issues.dlang.org/show_bug.cgi?id=14537 https://issues.dlang.org/show_bug.cgi?id=14178 https://issues.dlang.org/show_bug.cgi?id=14020 https://issues.dlang.org/show_bug.cgi?id=13870 https://issues.dlang.org/show_bug.cgi?id=13693

I also logged 5 yesterday.

On 11/29/2015 3:54 PM, Manu via Digitalmars-d wrote:
> I also logged 5 yesterday.

Thank you.

On Sunday, 29 November 2015 at 18:29:14 UTC, Walter Bright wrote:
> On 11/28/2015 8:40 PM, Manu via Digitalmars-d wrote:
>> The trouble mostly appears in this situation:
>>
>> file1.d
>>    extern(C++, NS) struct X;
>>
>> file2.d
>>    extern(C++, NS) struct Y;
>>
>> file3.d
>>    import file1, file2;
>>    X x; // nope
>>    Y y; // nope
>>    NS.X x; // NS has multiple definitions...
>>    NS.Y y; // NS has multiple definitions...
>
>     file1.NS.X x;
>     file2.NS.Y y;
>
> works.

Why not produce something similar to an overload set for C++ namespace ? An error needs to be issued only if X or Y is duplicated, otherwise, this is fine.

On 11/29/2015 8:31 PM, deadalnix wrote:
> On Sunday, 29 November 2015 at 18:29:14 UTC, Walter Bright wrote:
>> On 11/28/2015 8:40 PM, Manu via Digitalmars-d wrote:
>>> The trouble mostly appears in this situation:
>>>
>>> file1.d
>>>    extern(C++, NS) struct X;
>>>
>>> file2.d
>>>    extern(C++, NS) struct Y;
>>>
>>> file3.d
>>>    import file1, file2;
>>>    X x; // nope
>>>    Y y; // nope
>>>    NS.X x; // NS has multiple definitions...
>>>    NS.Y y; // NS has multiple definitions...
>>
>>     file1.NS.X x;
>>     file2.NS.Y y;
>>
>> works.
>
> Why not produce something similar to an overload set for C++ namespace ? An
> error needs to be issued only if X or Y is duplicated, otherwise, this is fine.

Because I'd rather have symbol table lookups done in a consistent manner, rather than special casing it everywhere. The above behavior is completely consistent with how everything else works, because it uses the exact same code.