After upgrading to 10.2 Tokyo one of third-party components started throwing a lot of exceptions. Debugging showed problematic part of code, that can be represented by this (hopefully) minimal code:
function foo(i: Integer): Boolean;
label bar;
begin
try
if i=1 then goto bar;
Result:=False;
EXIT;
bar:
Result:=True; //<~~ H2077 Value assigned to 'foo' never used with Optimization on
finally
end;
end;
With Optimization in compiler options set to
foo(1)
returns False
foo(1)
returns True
Such problem does not occur in XE7. This answer explaining changes in Tokyo's compiler is probably related - but maybe fixing some of the problems introduced new.
My question is: is it Tokyo's compiler defect? I am pretty sure it is, but I am new to programming in Delphi and it would be great to get confirmation from more experienced users.
If it is compiler's defect then I have a follow up question: is there any quick way to fix this code? I know how to remove goto
in my MCVE with simple if then else
statement, but real code is way more complicated:
if cond1 then goto bar;
if cond2 then goto bar;
if cond3 then goto bar;
...
if condN then goto bar;
And some of the if
blocks also contain loops with inner goto
. I know how to rewrite all of this logic to nested if then else
blocks, but maybe there is an easier way to fix it without waiting for compiler's defect or third-party component to be fixed (I know any of those won't happen soon).
This is a compiler defect. foo(1)
should return True
.
It looks like the optimiser is confused by this particular use of goto
.
Submit a bug report to Embarcadero. To get past the problem in the meantime you can:
goto
which appears to confuse the optimiser, orIf you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With