Bug 23497 – Erroneous escape reference to parameter error.

Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2022-11-20T02:08:58Z
Last change time
2022-12-15T22:50:01Z
Keywords
industry, pull
Assigned to
No Owner
Creator
deadalnix

Comments

Comment #0 by deadalnix — 2022-11-20T02:08:58Z
Sample code: class CompileError {} CompileError errorize(Type t) { return t.error; } struct Type { CompileError _error; void kind() {} @property auto error() in { kind(); } do { return _error; } } Compiling this sample code fails with the following error: "Error: returning `t.error()` escapes a reference to parameter `t`". This used to compile in 2.100, but fails in 2.101 and as far as I can tell, this is erroneous.
Comment #1 by razvan.nitu1305 — 2022-11-20T11:25:21Z
I guess the error may make sense. `t` is a struct and is going to get destroyed when `errorize` finishes execution. Since `t._error` is a reference type, a reference to `_error` is going to be escaped and then `t` is going to get destroyed and you end up with a reference to some destructed data. I am not advocating that the error should be issued, just saying that it could make sense. What is puzzling is that if you return `t._error` or if you comment the call to `kind()` in the in contract then the error goes away. Also, there is no -dip1000 or @safe involved so I don't know why the compiler is such a nagger.
Comment #2 by deadalnix — 2022-11-20T14:20:45Z
No, it's nonsense, and no reference to _error is going to escape. _error is a pointer, and it is returned by value. What escapes is a reference to the class instance _error points toward. Also, the in contract is somehow needed for the error to trigger, so something's not right either way.
Comment #3 by maxhaton — 2022-11-23T21:34:30Z
The `in` contract "causes" this to trigger because `kind` is neither explicitly declared nor inferred to be scope.
Comment #4 by deadalnix — 2022-11-27T01:28:14Z
There is nothing broken in that code and it used to work. So this is the end of this? That is some more DIP1000 related nonsense, isn't it?
Comment #5 by maxhaton — 2022-11-27T01:47:44Z
Yeah (I forgot to add more detail), it's broken. Something in the in block seems to make it think it should be noisy. Very hard to bisect because of the druntime merge.
Comment #6 by dlang-bot — 2022-12-08T23:00:02Z
@deadalnix created dlang/dmd pull request #14677 "Fix 23497" fixing this issue: - Fix 23497 This is achieved by reverting 4e7c4925772fe6e098d3a0736f25cb4fae4bce0b, which introduced the regression, and adding a new test case that ensure this specific regression doesn't happen again going forward. https://github.com/dlang/dmd/pull/14677
Comment #7 by dlang-bot — 2022-12-12T11:19:09Z
@dkorpel created dlang/dmd pull request #14686 "Fix 23497 - Erroneous escape reference to parameter error" fixing this issue: - Fix 23497 - Erroneous escape reference to parameter error https://github.com/dlang/dmd/pull/14686
Comment #8 by dlang-bot — 2022-12-12T22:13:55Z
dlang/dmd pull request #14686 "Fix 23497 - Erroneous escape reference to parameter error" was merged into stable: - 49a90204bc4859b8dc5515c681f47023f34c3436 by Dennis Korpel: Fix 23497 - Erroneous escape reference to parameter error https://github.com/dlang/dmd/pull/14686
Comment #9 by dlang-bot — 2022-12-15T22:50:01Z
dlang/dmd pull request #14701 "merge stable" was merged into master: - 52c5e2fbd41f7e8ae0a45be75ac74f9f6f5c6351 by Dennis Korpel: Fix 23497 - Erroneous escape reference to parameter error https://github.com/dlang/dmd/pull/14701