Bug 16949 – [Reg 2.073] confusing @safe error message for fields with unsafe destructors

Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2016-12-04T14:13:00Z
Last change time
2017-01-17T14:28:28Z
Keywords
diagnostic
Assigned to
nobody
Creator
code

Comments

Comment #0 by code — 2016-12-04T14:13:42Z
cat > bug.d << CODE struct A { ~this(){} } @safe struct B { A a; } CODE dmd -c bug -transition=safe ---- Error: cannot take address of parameter this in @safe function ~this ---- This should have been a deprecation instead of an error hidden by -transition=safe, hence it's a diagnostic regression. Also missing the line number btw. The original useful error message was. ---- bug.d(6): Error: @safe destructor 'bug.B.~this' cannot call @system destructor 'bug.A.~this' ----
Comment #1 by bugzilla — 2016-12-07T04:08:31Z
Already fixed: C:\cbx\bug>..\dmd test7 -transition=safe test7.d(6): Error: @safe destructor 'test7.B.~this' cannot call @system destructor 'test7.A.~this' C:\cbx\bug>..\dmd test7 test7.d(6): Error: @safe destructor 'test7.B.~this' cannot call @system destructor 'test7.A.~this'
Comment #2 by code — 2016-12-10T04:14:13Z
(In reply to Walter Bright from comment #1) > Already fixed: > > C:\cbx\bug>..\dmd test7 -transition=safe > test7.d(6): Error: @safe destructor 'test7.B.~this' cannot call @system > destructor 'test7.A.~this' Mmh, it's still broken in master, [Reg 2.073] is the current development version for the next release. It got fixed on the scope branch by https://github.com/dlang/dmd/commit/592824958312f0bf370f813631c4e6d0ff1862dc which allowed to take the address of variables in @safe code, thereby obviously nixing a check that prevents you from taking the address of a variable in @safe code. If you look at both commits https://github.com/dlang/dmd/commit/c871b7b2efb49933f8b103b775079c8731c98fa8 https://github.com/dlang/dmd/commit/592824958312f0bf370f813631c4e6d0ff1862dc The problematic code and it's fix sum up to: if ((dve.e1.op == TOKthis || dve.e1.op == TOKsuper) && global.params.safe) checkAddressVar(cast(ThisExp)dve.e1) checkAddressVar() { if (!v.canTakeAddressOf()) // this and super are never manifest variables error("bla"); if (sc.func && !sc.intypeof && !v.isDataseg()) // !global.params.safe was added in scope branch if (!global.params.safe && sc.func.setUnsafe()) error("this is the diagnostic regression error"); } If I understand this correctly the checkAddressVar call for this and super caused the diagnostic regression and is now a noop on the scope branch. How about we delete that part, both in master and on the scope branch?
Comment #3 by code — 2017-01-17T14:28:28Z
Works now, tested with dmd-master-2017-01-17 (-dip1000).