Macros confuse error message line number?

[Eugene Loza]

In some situations, like the example below, the error message points to $define instead of actual line where the error has happened:

Code: Pascal  [Select][+][-]

1. program Project1;
2. var
3.   A: TObject;
4.  
5. {$macro on}
6. {$define AObject:=(A as TObject)}
7.  
8. begin
9.   A := TObject.Create(nil)
10.   AObject.Tag := 0;
11.   A.Free;
12. end.

I wonder if there a way to effectively find the actual faulty line in code? In the example it's trivial - a forgotten semicolon and incorrect Create syntax. But when the macro is located inside of an include file and used a few dozens of times throughout a relatively large unit, debugging some trivial typos becomes slightly harder than necessary.

[MarkMLl]

Regrettably, that's the way it is and the way it's likely to stay.

Macro error placement can get very nasty if- as an example- a macro is associated with the name of a unit. Regrettably, in Real-World programming, such things are sometimes unavoidable.

MarkMLl

[PascalDragon]

In some situations, like the example below, the error message points to $define instead of actual line where the error has happened:

Correct, that is simply how macros work and we have no interest to change that.