How can I report what I think a compiler's frontend bug

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Sun Mar 20 14:46:15 PDT 2016


On 20 March 2016 at 20:06, Johan Engelen via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:

> On Sunday, 20 March 2016 at 17:57:12 UTC, Vincent R wrote:
>
>> On Sunday, 20 March 2016 at 16:16:18 UTC, Marco Leise wrote:
>>
>>> Am Sun, 20 Mar 2016 11:28:19 +0000
>>> schrieb Vincent R <lol at dlang.org>:
>>>
>>> Hi,
>>>>
>>>> I would like to start a new project (a bonjour/zeroconf wrapper
>>>> and a gui browser using it).
>>>> For the gui part I would like to use my existing skills using
>>>> wxWidgets wrapper (wxD).
>>>> So I have started to report a problem a few months ago:
>>>> https://forum.dlang.org/post/rtarlodeojnmedgsnscb@forum.dlang.org
>>>>
>>>> But so far(DMD32 D Compiler v2.070.2) it's still not fixed.
>>>> Do you think it will be fixed one day ?
>>>>
>>>> Thanks
>>>>
>>>
>>> Yes, I think it will be fixed one day, since - as you know
>>> by reading the very thread you linked - it is already reported
>>> and the GDC developers chimed in and considered it critical.
>>> There are also 118 open critical/blocker bugs that were
>>> reported before yours. Most of them by people here on the
>>> forums and you would need to explain to us why your bug
>>> deserves higher attention than the others (154 in total).
>>>
>>> Dlang is free open-source software and there is only a hand full of
>>> people who are fixing bugs in the compiler just for the sake of improving
>>> it. Most people contribute occasionally when they are interested in a
>>> solution to a particular problem.
>>>
>>> If you really need this fixed now ... you know the drill. I suggest you
>>> analyze the problem and start a discussion about it. Honestly asking why
>>> the compiler emits duplicate symbols in a reduced test case might have
>>> yielded you some good responses from the people who wrote the code.
>>>
>>
>> Ok first maybe it's already reported to GDC but to me it's not only a gdc
>> bug since it also happens with dmd. So I don't know how bugs are fixed in
>> the differents compilers but I suppose they share the same frontend (maybe
>> I am mistaken) and in this case I prefer not to wait for gdc developers to
>> fix it but to see if for instance some dmd developers have some time to fix
>> it.
>> I just want to use the language and don't have time to dig inside its
>> inner workings, so I think D is not for me. This project was the
>> opportunity to learn the language by fixing an unmaintained library (wxD)
>> but it's not as easy as I thought.
>>
>
> What may speed-up bug fixing a lot is preparing a nice testcase that is
> *as small as possible*.
> As you can see in the bug report [1], there is already a testcase. It is a
> good start, but it is not very minimal: contains a lot of comments etc.
> That is a lot of distraction / bother (for me at least). One way to help
> here is to minimize it further, and distill it down to the essential thing
> that appears to trigger the bug. You can do that without knowing any
> compiler internals.
> It can be very time consuming to make such a testcase, which may
> discourage developers fixing of your bug.
>
> [1] https://issues.dlang.org/show_bug.cgi?id=15324
>


I don't think it's a compiler bug, but it would help indefinitely if only
the compiler semantic passes checked for conflicting function overrides
upon declaration, rather than when they are called.

I can distil test case down to:

---
struct MultiIndexContainer()
{
    bool contains(int k) const
    {
        auto r = true;
        return r;
    }

    bool contains(int k) const
    {
        return false;
    }
}

void main()
{
    MultiIndexContainer!() m;
}

---

If these were not templates, you'd get multiple definition errors.  But as
that is not the case, these instead get put on comdat and merged. This as
you've discovered gives you an entirely different kind of linker error, but
it's simply a different side of the same coin.

The real bug is in the program logic.  Somehow, you have done the following
(abridged)
---
alias Value ValueView;
alias typeof(Value.init) KeyType;
bool contains(ValueView value) const { ... }
bool contains(KeyType k) const { ... }
---

You should add a constraint to ensure that ValueView != KeyType, or rename
the methods so as they don't conflict, such as containsValue() and
containsKey().

I'll post this in the bug report too.

Regards,
Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20160320/6b440c2a/attachment.html>


More information about the Digitalmars-d mailing list