Goto skips declaration

[Jonathan M Davis]

On Sunday, November 4, 2018 10:12:37 AM MST Michelle Long via Digitalmars-d 
wrote:
> On Saturday, 3 November 2018 at 21:55:56 UTC, lithium iodate
>
> wrote:
> > On Saturday, 3 November 2018 at 21:36:08 UTC, Michelle Long
> >
> > wrote:
> >> No, the problem actually exists. Simply because a simplified
> >> example does not produce the result does not mean it doesn't
> >> exist. The compiler does a lot of things so to suggest that I
> >> simply fabricated the error because the simplified
> >> demonstration case does not produce the error as pathetic.
> >>
> >> I got this error in my code and I simplified all the crap out
> >> of it to what I did that produced it and how I remedied it.
> >> It's not my fault you don't believe me.
> >
> > That's simply the to us accessible evidence speaking against
> > you. Check out DustMite if you haven't already, it's a tool for
> > automatically reducing code while maintaining a user-defined
> > condition, such as the equivalence of compiler output.
> > This thread will get nowhere as long as nobody can reproduce
> > the issue.
>
> Look, sometimes it is nearly impossible to reduce because the
> problem is far more complicated... also compilers do a lot of
> hacky shit like optimization or rewriting things that then hide
> the error when reduced.
>
> To try and act like it is my fault is ridiculous. Dustmite
> doesn't work. This is typical of dmd where nothing ever works as
> expected but the core group of people always seem to point
> fingers and expect the outsiders to deal with the mess they make.
>
> Do people here expect me to find all the bugs for D? Also expect
> me to fix them? Write proper tooling? Where does it end?
>
> When can someone just come in and say I've experienced a bug,
> this is what it `looks` like and then move on?
>
>
> The fact is, I explained the simple case and gave the error. This
> proves that either DMD has an issue or it has an issue.
>
> Building Win32\Debug\Demo.exe...
> test.d(164): Error: `goto` skips declaration of variable
>
> And when I simply wrap what follows in a block it compiles!
>
> That is enough to PROVE there is a bug somewhere. Either it is an
> issue with goto or some other compiler bug or a complex
> combination of problems, but all due to dmd.
>
> The fact that I can't produce a simple test case for others does
> not disprove this. The example I gave wasn't meant for a test
> case but to outline the problem. I thought it was a grammar
> related language decision. Either way, I would expect the
> "experts" to be able to figure out the real underlying issue
> immediately or after a few minutes of work. I guess I expect to
> much?
>
> But what happens is the flood of the tyrants who demand that I
> stop everything I'm doing and produce a test case that has the
> same bug so they can be convinced that such a bug exists come
> marching in! It's not like any of them(or almost) will do
> anything to fix the bug. In fact, many will say it's not a bug
> but a feature.
>
> In fact, given how long it takes for many bugs to get fixed in
> the D world(on the order of years), it is pointless.

Not having participated in this thread previously, and looking it over now,
it looks to me like there's a definite communication problem in this thread.
It's easy to believe that you found a bug in something like this a
complicated D program, but when you then give a simplified example and claim
it's buggy when that simplified example works, I don't think that it's
terribly surprising for folks to then turn around and say that you're wrong
about that code not working given that the code that you're showing _does_
work. It's rude if they claim that you're not seeing any bugs in your
program, but the way you presented the problem made it seem like you were
claiming that the simplified code snippets were broken, when they're not.
It's just the more complicated code which is hard to reduce into something
simple which is broken. And if you'd been clear about that up front, this
conversation probably would not have gotten as hotheaded.

But ultimately the problem with a bug like this (and I've hit annoying bugs
of my own that are very difficult to turn into simplified test cases) is
that unless you are able to provide a test case to the developers, the cold
hard reality is that the odds of them being able to do anything about the
problem are almost zero. Yes, if they stare at the code long enough, they
might be able to figure something out, but they probably won't, and they're
likely to just end up wasting their time even if they really, really want to
help you. A reproducible test case means a _lot_. And with all of the other
bugs that they could be working on which do have reproducible test cases,
they're not likely to spend their time on one where pretty much all they
have to go on is someone giving them an error message. They _need_ to be
able to reproduce the problem themselves.

And while it would be great if you could provide something that was no more
than a dozen lines of codes, even if the best you can do is provide a 10,000
line module that reproduced the problem in a bug report, at least if you
were able to do that, then the developers would have something to work with.
But regardless of the length of the example you provide, without a bug
report, the developers aren't going to do anything. Please report your issue
in bugzilla with the smallest piece of code that you can, even if that piece
of code is annoyingly big:

https://issues.dlang.org

That at least makes it _possible_ for someone to reproduce the problem and
try to track it down, whereas right now, no one can help you, because you
haven't reported the bug in bugzilla, and you haven't given enough
information to reproduce the problem.

- Jonathan M Davis