H2077内部尝试最终阻止goto - 这是东京的编译器缺陷吗?

时间:2017-09-21 16:54:14

标签: delphi delphi-10.2-tokyo

升级到10.2东京后,第三方组件之一开始抛出很多例外。调试显示了有问题的代码部分,可以用这个(希望)最小代码来表示:

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;

将编译器选项中的 Optimization 设置为

  • True(发布配置的默认设置) - foo(1)返回False
  • False(调试配置的默认设置) - foo(1)返回True

XE7中不会出现此类问题。 This answer解释东京编译器的变化可能是相关的 - 但可能会修复一些新引入的问题。

我的问题是: 它是东京的编译器缺陷吗?我很确定它是,但我是Delphi编程的新手,很高兴得到更有经验的用户的确认。

如果是编译器的缺陷,那么我有一个跟进问题:是否有任何快速方法来修复此代码?我知道如何使用简单的goto语句删除我的MCVE中的if then else,但实际代码更复杂:

if cond1 then goto bar;
if cond2 then goto bar;
if cond3 then goto bar;
...
if condN then goto bar;

一些if块也包含内部goto的循环。我知道如何将所有这些逻辑重写为嵌套的if then else块,但也许有一种更简单的方法来修复它而无需等待编译器的缺陷或第三方组件被修复(我知道任何一个)那些不久就会发生的事情。)

1 个答案:

答案 0 :(得分:7)

这是一个编译器缺陷。 foo(1)应该返回True。 看起来优化器对goto的这种特殊用法感到困惑。

向Embarcadero提交错误报告。要在此期间解决问题,您可以:

  • 与第三方组件供应商联系并要求解决方法或
  • 重新编写代码以避免显示混淆优化器的goto,或
  • 恢复为无缺陷的旧版本编译器,或
  • 禁用受缺陷影响的任何功能的优化。