www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How does rt_finalized function work exactly? (Fixing bugs regarding

reply 12345swordy <alexanderheistermann gmail.com> writes:
I can't find any documentation nor can I find any information 
regarding it's implementation. I am asking this, as I focusing on 
fixing bugs that destroy currently has, most noticeably bugs 
regarding attributes. I am not sure that this requires a DIP in 
order to fix this.

https://issues.dlang.org/show_bug.cgi?id=17297
https://issues.dlang.org/show_bug.cgi?id=15246
Jan 19 2018
next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Friday, 19 January 2018 at 15:56:58 UTC, 12345swordy wrote:

 I can't find any documentation nor can I find any information 
 regarding it's implementation. I am asking this, as I focusing 
 on fixing bugs that destroy currently has, most noticeably bugs 
 regarding attributes. I am not sure that this requires a DIP in 
 order to fix this.

 https://issues.dlang.org/show_bug.cgi?id=17297
 https://issues.dlang.org/show_bug.cgi?id=15246


You'll probably learn new and interesting things but i warn you: 
this problem can't be fixed.

Look at here: 
https://github.com/dlang/druntime/blob/master/src/rt/lifetime.d#L1380.
rt_finalize calls rt_finalize2 which use the **dynamic** type 
info to get a pointer to the __xdtor of each generation.
Jan 19 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 19 January 2018 at 16:18:15 UTC, Basile B. wrote:

this problem can't be fixed.


You need to specify, do you mean this can't be fixed without a 
DIP or even with a DIP?
Jan 19 2018
parent Basile B. <b2.temp gmx.com> writes:
On Friday, 19 January 2018 at 17:01:50 UTC, 12345swordy wrote:

 On Friday, 19 January 2018 at 16:18:15 UTC, Basile B. wrote:

this problem can't be fixed.


 You need to specify, do you mean this can't be fixed without a 
 DIP or even with a DIP?


I meant: at all. But i'd like to be wrong.
Jan 19 2018
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Friday, 19 January 2018 at 15:56:58 UTC, 12345swordy wrote:

 I can't find any documentation nor can I find any information 
 regarding it's implementation. I am asking this, as I focusing 
 on fixing bugs that destroy currently has, most noticeably bugs 
 regarding attributes. I am not sure that this requires a DIP in 
 order to fix this.

 https://issues.dlang.org/show_bug.cgi?id=17297
 https://issues.dlang.org/show_bug.cgi?id=15246


Have a look here: 
https://github.com/dlang/druntime/blob/master/src/rt/lifetime.d#L1380
Jan 19 2018
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/19/18 10:56 AM, 12345swordy wrote:

 I can't find any documentation nor can I find any information regarding 
 it's implementation. I am asking this, as I focusing on fixing bugs that 
 destroy currently has, most noticeably bugs regarding attributes. I am 
 not sure that this requires a DIP in order to fix this.
 
 https://issues.dlang.org/show_bug.cgi?id=17297
 https://issues.dlang.org/show_bug.cgi?id=15246


So there has been very little definition around how destructors use and 
inherit attributes. Most of this is because destructors are generally 
called from the GC, where it doesn't matter at all what the attributes are.

I think before you can fix such things, we need a clear model of how the 
destructors are called, and what is inherited and what is overridden in 
base classes. Then we can think about how to fix the situation.

Note that:

a. The GC must have a *runtime* definition of how to call the 
destructors. And we need to statically disallow the GC from calling 
destructors it shouldn't be allowed to call (if such cases exist).
b. Object.~this can't be a decider of what the attributes should be, as 
this prevents adding any additional attributes.
c. There is a push recently (by Andrei and Lucia and others) to remove 
some of the "magic" calls from the compiler, and replace them with 
templates, so we can have more library control over what happens (and 
more comiple-time introspection). This should help quite a bit in the 
implementation of such things. But we definitely are limited by the 
virtual-ness of Objects, and the opaqueness of the GC.

-Steve
Jan 19 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 19 January 2018 at 18:22:33 UTC, Steven Schveighoffer 
wrote:

 On 1/19/18 10:56 AM, 12345swordy wrote:

 I can't find any documentation nor can I find any information 
 regarding it's implementation. I am asking this, as I focusing 
 on fixing bugs that destroy currently has, most noticeably 
 bugs regarding attributes. I am not sure that this requires a 
 DIP in order to fix this.
 
 https://issues.dlang.org/show_bug.cgi?id=17297
 https://issues.dlang.org/show_bug.cgi?id=15246


 So there has been very little definition around how destructors 
 use and inherit attributes. Most of this is because destructors 
 are generally called from the GC, where it doesn't matter at 
 all what the attributes are.

 I think before you can fix such things, we need a clear model 
 of how the destructors are called, and what is inherited and 
 what is overridden in base classes. Then we can think about how 
 to fix the situation.

 Note that:

 a. The GC must have a *runtime* definition of how to call the 
 destructors. And we need to statically disallow the GC from 
 calling destructors it shouldn't be allowed to call (if such 
 cases exist).
 b. Object.~this can't be a decider of what the attributes 
 should be, as this prevents adding any additional attributes.
 c. There is a push recently (by Andrei and Lucia and others) to 
 remove some of the "magic" calls from the compiler, and replace 
 them with templates, so we can have more library control over 
 what happens (and more comiple-time introspection). This should 
 help quite a bit in the implementation of such things. But we 
 definitely are limited by the virtual-ness of Objects, and the 
 opaqueness of the GC.

 -Steve


I see, this does look like it needs a DIP in order to fix this. 
How the progress of the calls being replaced by templates by 
Andrei and company?
Jan 19 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/19/18 2:48 PM, 12345swordy wrote:

 I see, this does look like it needs a DIP in order to fix this. How the 
 progress of the calls being replaced by templates by Andrei and company?


Here are the improvements that Lucia is doing/has done, which is a lot 
of good stuff:

https://github.com/dlang/druntime/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Asomzzz

But really, I think we need a DIP to clarify the model of destructors 
and attribute inheritance. Right now, there is nothing (just that you 
can have attributes): https://dlang.org/spec/class.html#destructors

There are some notes about destructors in the attributes section, e.g. 
"Pure destructors do not benefit of special elision." But there is 
nothing talking about how the attributes are inherited, or rules about 
when they can be called.

I would love for Object to have it's attribute shackles removed. It's 
not just destructors, but toString, opCmp, etc.

-Steve
Jan 19 2018
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 19 January 2018 at 20:21:44 UTC, Steven Schveighoffer 
wrote:

 On 1/19/18 2:48 PM, 12345swordy wrote:

 [...]


 Here are the improvements that Lucia is doing/has done, which 
 is a lot of good stuff:

 [...]


I found out that this fix does require a DIP. (Thanks Walker!)
Jan 24 2018