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
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
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
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
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
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
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
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
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