Bug 17559 – [REG2.073.0] Wrong line number in stack trace

Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
x86_64
OS
Linux
Creation time
2017-06-26T17:13:00Z
Last change time
2017-12-18T22:54:32Z
Keywords
pull, symdeb
Assigned to
No Owner
Creator
Vladimir Panteleev

Comments

Comment #0 by dlang-bugzilla — 2017-06-26T17:13:00Z
///////////// test.d ///////////// import mod; void main() { fun(1); fun(2); fun(3); fun(4); } ////////////// mod.d ///////////// void fun(int n, int defParam = 10) { assert(n != 4); } ////////////////////////////////// Test command: dmd -g test.d mod.d ; ./test 2>&1 | grep _Dmain Output with 2.072.2: test.d:8 _Dmain [0x427dc7] Output with 2.073.0: test.d:5 _Dmain [0x427d37] The correct line number is 8, not 5. Introduced in https://github.com/dlang/dmd/pull/6327
Comment #1 by r.sagitario — 2017-06-26T17:56:52Z
Works alright on Windows. Anything special in mod.d or can it be omitted?
Comment #2 by dlang-bugzilla — 2017-06-26T18:18:49Z
(In reply to Rainer Schuetze from comment #1) > Works alright on Windows. Linux x64 here. > Anything special in mod.d or can it be omitted? If fun is in the same file as main, the line number still changes between versions, but it points at the line containing fun's signature. That's not so bad - it's not useful but at least it's not misleading wrong, as when fun is in a separate module.
Comment #3 by r.sagitario — 2017-06-26T21:43:23Z
Ok, I can reproduce it with Win64 if I remove the (bad) condition that disallows decreasing line numbers.
Comment #4 by r.sagitario — 2017-06-27T07:32:05Z
You get the same result without default parameters, too: ///////////// test.d ///////////// import mod; void main() { fun(1, 10); fun(2, 10); fun(3, 10); fun(4, 10); } ////////////// mod.d ///////////// void fun(int n, int defParam) { assert(n != 4); } ////////////////////////////////// The problem seems to be that the backend always performs common sub expression elimination, mapping all instances of "10" to the same expression instance and then emitting its location. I suspect this exists since forever, but I haven't tried older versions yet.
Comment #5 by bugzilla — 2017-06-28T22:22:55Z
This is not a regression. The code deleted by https://github.com/dlang/dmd/pull/6947 has been there for 30 years.
Comment #6 by dlang-bugzilla — 2017-06-28T22:24:58Z
How do you define a regression? If something worked and now it doesn't work then it's a regression from the user's perspective. When latent bugs are exposed by some change or another, it doesn't matter how long said bugs were there.
Comment #7 by r.sagitario — 2017-10-07T14:50:09Z
Comment #8 by github-bugzilla — 2017-11-18T06:51:49Z
Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/127d639b6bbd82d1294da884a97de310e52985e0 fix issue 17559 - [REG2.073.0] Wrong line number in stack trace only emit line number info for the first emission of common sub expressions https://github.com/dlang/dmd/commit/c6a948b0bf11ce8a34d49614155507c1cb687484 Merge pull request #6947 from rainers/issue17559 fix issue 17559 - [REG2.073.0] Wrong line number in stack trace
Comment #9 by github-bugzilla — 2017-12-18T22:54:32Z
Commits pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/127d639b6bbd82d1294da884a97de310e52985e0 fix issue 17559 - [REG2.073.0] Wrong line number in stack trace https://github.com/dlang/dmd/commit/c6a948b0bf11ce8a34d49614155507c1cb687484 Merge pull request #6947 from rainers/issue17559