Is this a bug? +goto

[Michelle Long]

On Thursday, 8 November 2018 at 02:22:42 UTC, Jonathan M Davis 
wrote:
> On Wednesday, November 7, 2018 1:03:47 PM MST Michelle Long via 
> Digitalmars- d-learn wrote:
>> Don't let their psychobabble fool you. They are wrong and you 
>> were right from the start.
>
> ...
>
>> Case A:
>> {
>>     if (true) goto X;
>>     int x;
>> }
>> X:
>>
>>
>> Case B:
>> {
>>     if (true) goto X;
>>     {
>>        int x;
>>     }
>> }
>> X:
>>
>>
>> These two cases are EXACTLY the same semantically. It's like
>> writing A + B and (A + B).
>
> That's not the situation that the OP was describing. If adding 
> braces in a situation where the braces have no semantic effect 
> has any impact on goto, then it's a compiler bug. It's adding a 
> new scope that affects the lifetime of a variable whose 
> declaration is being jumped over by a goto that matters.
>
> I know that you're frustrated, because you've hit a problem 
> with goto in complex code, and you don't have a simple example 
> that shows the compiler bug, but the approach that D takes with 
> goto (and any construct that potentially requires code flow 
> analysis) of avoiding requiring that the compiler be smart is 
> precisely to reduce the risk of there being cases where the 
> compiler is going to screw it up in complex code even though it 
> gets it right in the simple cases. If the language required the 
> compiler to be smart about such things, we'd have a lot more 
> problems with subtle, hard to track down compiler bugs in 
> complex code. So, we'd just have _more_ cases where people 
> would be hitting frustrating bugs like you are.

That's fine. The D compiler writers can decide to do whatever 
they want. I can simply take my "business" elsewhere if I don't 
like it.

What I am talking about is about an obvious error(Ok, I haven't 
produced a simplified test case but dustmite or visual D is not 
working for me to do so at this point in time, but it would be 
nice for sake of argument to assume I'm right...).

> Regardless, if you want to actually have your problem fixed, 
> you're going to need to provide a reproducible test case in a 
> bugzilla report, even if it's large, otherwise no one is going 
> to be able to track it down for you.

That's easier said than done. I wasn't expecting anyone to be 
able to fix a bug that can't be reproduced.

What I expect is that, given my assumptions that I'm right, that 
people can agree the compiler does have a bug or flaw that can 
easily be fixed give then two simplified test cases basic purely 
what I have done in my own code.

1.

foreach(...)
{
   if (x) goto Y:
   int z;
}
Y:

Fails.

foreach(...)
{
   if (x) goto Y:
   {
      int z;
   }
}
Y:

Passes.

THAT IS FACT! It doesn't matter if the examples work above. I 
have simplified what I have done and in my code I simply add 
brackets and it works! That is what people should be thinking 
about... not test cases, MWE's, compiler versions, etc.

Is it logical that the compiler **should** error out in the first 
case and no in the second?

That is what the discussion is ALL about. Once that is dealt with 
then we can move on to finding out more specifics. There is no 
reason to build the windows of a house before the foundation, 
it's just far more work without any benefit.


Once people can say: If that is all you are doing is adding 
brackets around what follows the goto and break out of 
scope(which is what the code above says) and you can compile, 
then it is a compiler bug or flaw.

Once people verify that, rather than trying to create rabbit 
holes, then I can do more work on finding out more specifics. 
Until then, it is pointless to do anything on my side because if 
people come back and say "No, it is suppose to work that way" 
then what the hell am I trying to simplify and fix? It's not a 
bug then.


But what it seems is that people cannot reason about the purely 
theoretical underpinnings of the problem and need proof that 
there is even a problem in the first place, as if I'm making it 
up and then they create all kinds of obfuscation that doesn't 
help anyone.

If you can agree that removing the brackets in the two test cases 
should work in ALL regular cases then I can attempt to provide 
more information.

Again, until then, it is pointless. I could waste 10 hours trying 
to track the issue down to provide a test case and you can just 
come back and say "Oh, no, that is not a bug, it's suppose to be 
that way. We will not change anything". I know from previous 
history that is the typical mentality.

Until We can agree that it is a bug, it is pointless for me to 
treat it as a bug.



> Now, a goto-related regression has recently been reported for 
> joiner:
>
> https://issues.dlang.org/show_bug.cgi?id=19213
>
> where some code worked with joiner in 2.081.2 but does not work 
> with 2.082.0 or later, so you may want to test your code with 
> an older compiler release to see if you've hit a compiler 
> regression. If so, that could be a starting point for tracking 
> down the problem.
>

Until I can simplify the code I have, it won't matter. If it is 
the same bug, then it will get fixed when it gets fixed with 
joiner. If it is a different bug, then it will get fixed with I 
can produce a test case.

While I could prove that it is a version issue by trying a 
different compiler version(I guess I should keep an old one 
around for that purpose) it seems it is likely that it is the 
same bug...