德尔福XE2 : Off by 7-20 lines in debugger and compiler error line numbers also off by the same amount

Question

我在工作的大型 Delphi 代码库中遇到问题，作为从 Delphi 2007 移植到 XE2 的副作用，我们现在遇到以下奇怪的相关问题:

• 即使在调试版本中也无法设置断点或单步执行代码，因为行编号全部困惑，仅在某些单元中。

• 故意在第 2010 行引入语法错误将导致光标聚焦在第 2020 行，给出或减去 3 或 4 行，如下所示:

.

 procedure Correct;
 begin
    DoSomething; // syntax error reported HERE but the real error is below.
    // more stuff here.
 end;

 procedure OllKorrect;  
 begin
        ThisLineIsFine();
        __VARIABLE_NOT_DEFINED__ := 1; // intentional error
 end

我希望有人以前见过这个。该问题的要素可能包括:

代码中包含许多奇怪的编译器指令，例如 {$REALCOMPATIBILITY ON} 和 {$H-}/{$H+} 指令，代码中包含数千个 {$H+}/{$H-} 指令。

其次，代码使用了大量的 {$I INCLUDE} 指令，我怀疑包含文件可能会直接扰乱编译器的行编号。

我无法肯定地说，但我怀疑所有这些旧的“使其像 DOS 的 Turbo pascal 一样工作”编译器开关是其背后的原因。我想知道是否有人确切知道这件事。它只发生在代码中的某些地方，对于一个拥有超过 500 个单元的项目，其中一些单元的大小达到 10K/20KLOC，这绝对是令人沮丧的。我能说的是，不仅具有 {$I include.inc} 指令的单元会造成困惑，而且许多包含大量 {$H-}/{$H+} 或 {$REALCOMPATIBILITY} 指令的单元也会造成困惑没有这个问题。如果我能看出行为不端的单位有什么共同点，我就能弄清楚这一点。

更新:线路终止问题是有道理的。我运行这段代码发现了问题。修复代码被注释掉，因为如果您取消注释它并且它会删除所有源代码，那就是您的问题。它将非 unicode 文件加载到 unicode TStringList 中并将其保存回来。在我的世界里这没关系，因为它的所有版本都受到控制和备份。您的里程可能会有所不同。

program linefeedsProject1;

{$APPTYPE CONSOLE}

uses
  IOUtils,
  Classes,
  Types,
  SysUtils;


  var
    broken,notBroken:Integer;

  function fix(filename:String):Boolean;
  var
    sl:TStringList;
  begin
    sl := TStringList.Create;
    try
    sl.LoadFromFile(filename);
    //TODO:Change file extensions.
    sl.SaveToFile(filename);
    finally
      sl.Free;
    end;
  end;

  function scan(filename:String):Boolean;
  var
  crFlag:Boolean;
  lfFlag:Boolean;
  missingCr:Integer;
  missingLf:Integer;
   f:TFileStream;
   buf:Array[0..1024] of AnsiChar;
   n:Integer;
   procedure scanChars;
   var
    i:Integer;
   begin
     for i := 0 to n-1 do
     begin
       if buf[i]=#13 then
       begin
          crFlag := true;
          lfFlag := false;
       end
       else if buf[i]=#10 then
       begin
           if not crFlag then
            inc(missingCr);
          lfFlag := true;
          crFlag := false;
       end
       else begin
         if (crFlag) then
          inc(missingLf);
         crFlag := false;
         lfFlag := false;
       end;
     end;
   end;
  begin
   result := false;
   crFlag := false;
   lfFlag := false;
   missingCr := 0;
   missingLf := 0;
    f := TFileStream.Create(filename, fmOpenRead);
    try
      while f.Position< f.Size do
      begin
        n := f.Read(buf[0],1024);
        scanChars;
      end;

     if (missingCr>0) or (missingLf>0) then
     begin
          WriteLn('  ', filename);
          Inc(broken);
          result := true;
     end
     else
     begin
        Inc(notBroken);
     end
    finally
      f.Free;
    end;

  end;
var
 files:TStringDynArray;
 afile:String;
 begin
  try
  broken := 0;
  notBroken := 0;
    files := TDirectory.GetFiles('C:\dev\abackupcopyofyoursourcecode',  '*.pas',
    TSearchOption.soTopDirectoryOnly );
    // tried TSearchOption.soAllDirectories and it exploded. not recommended.

    for afile in files do
    begin
       if scan(afile) then
       begin
           // fix(afile); // uncomment at your own risk and only on a backup copy of your code.
       end;

    end;


    WriteLn('Broken ', broken);
    WriteLn('not broken ',notBroken);

   // readln;

     except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

Update 2: If you want a scanner/fixer for this issue you can download mine (with source) here.链接是谷歌云端硬盘。您可以从链接查看源代码，但单击"file"下拉菜单(Google Drive Web 用户界面的一部分)，然后单击“下载”进行下载。

Answer 1

我以前见过这样的事情，IME 这通常是由于计算行数时的编译器错误造成的。如果在某些地方有非标准换行符(不是 CRLF)(这种情况可能会发生)，IDE 会执行正确的换行符，但编译器不会将它们计为新行，因此之后的所有内容都会被减一。

当我遇到这样的文件时，我所做的就是在 EditPad 中打开它，将所有换行符转换为其他样式(Unix 或 Mac 样式)，然后将所有换行符转换为 Windows 样式并保存。这可确保文件中的每一行都以 CRLF 结尾，并且在重建后，蓝点未正确排列的问题就会消失。