Issue 13229 - RangeError in inlined function prints wrong module name (but right line)
Summary: RangeError in inlined function prints wrong module name (but right line)
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All All
: P1 normal
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-30 22:07 UTC by Ivan Kazmenko
Modified: 2022-08-25 14:33 UTC (History)
1 user (show)

See Also:


Attachments
module caller.d (95 bytes, text/plain)
2014-07-30 22:14 UTC, Ivan Kazmenko
Details
module other.d (60 bytes, text/plain)
2014-07-30 22:14 UTC, Ivan Kazmenko
Details

Note You need to log in before you can comment on or make changes to this issue.
Description Ivan Kazmenko 2014-07-30 22:07:01 UTC
When a range violation occurs in an inlined function, the error message mentions the module which calls that function, not the module where it is defined.  However, the line number corresponds to the file where the function is defined.

As this points to a wrong line of the source, the error can be very confusing the first time you encounter it.  It surely looks like "debug capabilities broken".

-----caller.d-----
module caller;
import other;

// lines 3-5 contain no code

void main () {
	fun (2);
}
-----

-----other.d-----
module other;
int [2] x;
void fun (int i) {
	x[i]++;
}
-----

When we run "dmd caller.d other.d", we get the correct message:
core.exception.RangeError@other.d(4): Range violation

However, add -inline, as in "dmd -inline caller.d other.d", and we see the error:
core.exception.RangeError@caller.d(4): Range violation

As you can see, line 4 of caller.d contains only a comment and so can not generate any errors.

This is reproducible for me on DMD 2.065.0 and DMD 2.066.0-b6 on Win32 and Win64.
Comment 1 Ivan Kazmenko 2014-07-30 22:14:34 UTC
Created attachment 1375 [details]
module caller.d
Comment 2 Ivan Kazmenko 2014-07-30 22:14:48 UTC
Created attachment 1376 [details]
module other.d
Comment 3 RazvanN 2022-08-25 14:33:10 UTC
I cannot reproduce this with the latest compiler. Seems to have been fixed.