On 26 January 2011 11:17, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Wednesday 26 January 2011 01:58:50 Don Clugston wrote:
>> On 26 January 2011 10:32, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>> > How else would an error be thrown?
>>
>> In many cases, it's thrown by hardware. The exception object is
>> created long after the throw occurred.
>> There are also 'foreign' exceptions, which are thrown by (say) C++.
>>
>> (I suspect that Linux DMD can't handle any of those -- but Windows DMD
>> can).
>
> So, what exactly about that makes it a problem that the file and line number have default arguments? If it gives the arguments (like it pretty much has to be doing),

No, it doesn't give the arguments. It has no way of knowing what they are (in fact, they may not even exist at all).

then it doesn't use the defaults, so they don't cause any problems
> there. And is it only file and line number which cause problems if they have defaults, or is it everything (e.g. Throwable next)?

It's only file and line number that are a problem. next will just be null.
The thing which you're maybe not understanding is that in these cases,
the exception object is created when it is caught, not when it is
thrown.

On Wednesday 26 January 2011 03:02:55 Don Clugston wrote:
> On 26 January 2011 11:17, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > On Wednesday 26 January 2011 01:58:50 Don Clugston wrote:
> >> On 26 January 2011 10:32, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> >> > How else would an error be thrown?
> >> 
> >> In many cases, it's thrown by hardware. The exception object is
> >> created long after the throw occurred.
> >> There are also 'foreign' exceptions, which are thrown by (say) C++.
> >> 
> >> (I suspect that Linux DMD can't handle any of those -- but Windows DMD
> >> can).
> > 
> > So, what exactly about that makes it a problem that the file and line number have default arguments? If it gives the arguments (like it pretty much has to be doing),
> 
> No, it doesn't give the arguments. It has no way of knowing what they are (in fact, they may not even exist at all).
> 
> then it doesn't use the defaults, so they don't cause any problems
> 
> > there. And is it only file and line number which cause problems if they have defaults, or is it everything (e.g. Throwable next)?
> 
> It's only file and line number that are a problem. next will just be null.
> The thing which you're maybe not understanding is that in these cases,
> the exception object is created when it is caught, not when it is
> thrown.

Well, I certainly I have no clue about what is really going on then, and it would probably take a fair bit of discussion and/or research for me to understand. Obviously, there's stuff going on here that's at a far lower level than I'm used to dealing with.

Regardless, is it all Throwables that have the problem, or is it just Throwable, Exception, and or Error? Throwable and Error really shouldn't be a problem, since programmers wouldn't normally be creating those (at most, they'd be creating objects derived from them), but you definitely lose something if Exception has the problem as well. And you _definitely_ lose something if _all_ Throwables have the problem. In any case, I need to know which ones are a problem if I'm going to fix them.

- Jonathan M Davis

On 26 January 2011 12:21, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Wednesday 26 January 2011 03:02:55 Don Clugston wrote:
>> On 26 January 2011 11:17, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>> > On Wednesday 26 January 2011 01:58:50 Don Clugston wrote:
>> >> On 26 January 2011 10:32, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>> >> > How else would an error be thrown?
>> >>
>> >> In many cases, it's thrown by hardware. The exception object is
>> >> created long after the throw occurred.
>> >> There are also 'foreign' exceptions, which are thrown by (say) C++.
>> >>
>> >> (I suspect that Linux DMD can't handle any of those -- but Windows DMD
>> >> can).
>> >
>> > So, what exactly about that makes it a problem that the file and line number have default arguments? If it gives the arguments (like it pretty much has to be doing),
>>
>> No, it doesn't give the arguments. It has no way of knowing what they are (in fact, they may not even exist at all).
>>
>> then it doesn't use the defaults, so they don't cause any problems
>>
>> > there. And is it only file and line number which cause problems if they have defaults, or is it everything (e.g. Throwable next)?
>>
>> It's only file and line number that are a problem. next will just be null.
>> The thing which you're maybe not understanding is that in these cases,
>> the exception object is created when it is caught, not when it is
>> thrown.
>
> Well, I certainly I have no clue about what is really going on then, and it would probably take a fair bit of discussion and/or research for me to understand. Obviously, there's stuff going on here that's at a far lower level than I'm used to dealing with.

Yeah, it's a bit hairy. It took me a few weeks to work out what's going on.
There's all kinds of weird stuff, where you make function calls that
never return, because the stack disappears...
In the end, the whole thing is an elaborate illusion that gives you a
really nice model to program against.
Fortunately, all of the weirdness is confined to a very small number
of functions.

> Regardless, is it all Throwables that have the problem, or is it just Throwable, Exception, and or Error? Throwable and Error really shouldn't be a problem, since programmers wouldn't normally be creating those (at most, they'd be creating objects derived from them), but you definitely lose something if Exception has the problem as well. And you _definitely_ lose something if _all_ Throwables have the problem. In any case, I need to know which ones are a problem if I'm going to fix them.

It is only Throwable, and Error. Not anything derived from them. (Really, I think both of those should eventually become abstract classes anyway. Not right now, because compiler changes are required).

On Wednesday 26 January 2011 04:35:13 Don Clugston wrote:
> On 26 January 2011 12:21, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > On Wednesday 26 January 2011 03:02:55 Don Clugston wrote:
> >> On 26 January 2011 11:17, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> >> > On Wednesday 26 January 2011 01:58:50 Don Clugston wrote:
> >> >> On 26 January 2011 10:32, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> >> >> > How else would an error be thrown?
> >> >> 
> >> >> In many cases, it's thrown by hardware. The exception object is
> >> >> created long after the throw occurred.
> >> >> There are also 'foreign' exceptions, which are thrown by (say) C++.
> >> >> 
> >> >> (I suspect that Linux DMD can't handle any of those -- but Windows
> >> >> DMD can).
> >> > 
> >> > So, what exactly about that makes it a problem that the file and line number have default arguments? If it gives the arguments (like it pretty much has to be doing),
> >> 
> >> No, it doesn't give the arguments. It has no way of knowing what they are (in fact, they may not even exist at all).
> >> 
> >> then it doesn't use the defaults, so they don't cause any problems
> >> 
> >> > there. And is it only file and line number which cause problems if they have defaults, or is it everything (e.g. Throwable next)?
> >> 
> >> It's only file and line number that are a problem. next will just be null. The thing which you're maybe not understanding is that in these cases, the exception object is created when it is caught, not when it is thrown.
> > 
> > Well, I certainly I have no clue about what is really going on then, and it would probably take a fair bit of discussion and/or research for me to understand. Obviously, there's stuff going on here that's at a far lower level than I'm used to dealing with.
> 
> Yeah, it's a bit hairy. It took me a few weeks to work out what's going on.
> There's all kinds of weird stuff, where you make function calls that
> never return, because the stack disappears...
> In the end, the whole thing is an elaborate illusion that gives you a
> really nice model to program against.
> Fortunately, all of the weirdness is confined to a very small number
> of functions.
> 
> > Regardless, is it all Throwables that have the problem, or is it just Throwable, Exception, and or Error? Throwable and Error really shouldn't be a problem, since programmers wouldn't normally be creating those (at most, they'd be creating objects derived from them), but you definitely lose something if Exception has the problem as well. And you _definitely_ lose something if _all_ Throwables have the problem. In any case, I need to know which ones are a problem if I'm going to fix them.
> 
> It is only Throwable, and Error. Not anything derived from them. (Really, I think both of those should eventually become abstract classes anyway. Not right now, because compiler changes are required).

Well, that shouldn't be much of a problem then. I really would have expected them to be abstract anyway. I'll check in a fix shortly.

- Jonathan M Davis

On 1/26/2011 8:51 AM, Jonathan M Davis wrote:
> On Wednesday 26 January 2011 04:35:13 Don Clugston wrote:
>> On 26 January 2011 12:21, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>> On Wednesday 26 January 2011 03:02:55 Don Clugston wrote:
>>>> On 26 January 2011 11:17, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>>>> On Wednesday 26 January 2011 01:58:50 Don Clugston wrote:
>>>>>> On 26 January 2011 10:32, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>>>>>> How else would an error be thrown?
>>>>>>
>>>>>> In many cases, it's thrown by hardware. The exception object is
>>>>>> created long after the throw occurred.
>>>>>> There are also 'foreign' exceptions, which are thrown by (say) C++.
>>>>>>
>>>>>> (I suspect that Linux DMD can't handle any of those -- but Windows
>>>>>> DMD can).
>>>>>
>>>>> So, what exactly about that makes it a problem that the file and line number have default arguments? If it gives the arguments (like it pretty much has to be doing),
>>>>
>>>> No, it doesn't give the arguments. It has no way of knowing what they are (in fact, they may not even exist at all).
>>>>
>>>> then it doesn't use the defaults, so they don't cause any problems
>>>>
>>>>> there. And is it only file and line number which cause problems if they have defaults, or is it everything (e.g. Throwable next)?
>>>>
>>>> It's only file and line number that are a problem. next will just be null. The thing which you're maybe not understanding is that in these cases, the exception object is created when it is caught, not when it is thrown.
>>>
>>> Well, I certainly I have no clue about what is really going on then, and it would probably take a fair bit of discussion and/or research for me to understand. Obviously, there's stuff going on here that's at a far lower level than I'm used to dealing with.
>>
>> Yeah, it's a bit hairy. It took me a few weeks to work out what's going on.
>> There's all kinds of weird stuff, where you make function calls that
>> never return, because the stack disappears...
>> In the end, the whole thing is an elaborate illusion that gives you a
>> really nice model to program against.
>> Fortunately, all of the weirdness is confined to a very small number
>> of functions.
>>
>>> Regardless, is it all Throwables that have the problem, or is it just Throwable, Exception, and or Error? Throwable and Error really shouldn't be a problem, since programmers wouldn't normally be creating those (at most, they'd be creating objects derived from them), but you definitely lose something if Exception has the problem as well. And you _definitely_ lose something if _all_ Throwables have the problem. In any case, I need to know which ones are a problem if I'm going to fix them.
>>
>> It is only Throwable, and Error. Not anything derived from them. (Really, I think both of those should eventually become abstract classes anyway. Not right now, because compiler changes are required).
> 
> Well, that shouldn't be much of a problem then. I really would have expected them to be abstract anyway. I'll check in a fix shortly.
> 
> - Jonathan M Davis
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

Hrm.. the revert didn't make the problem go away:

http://d.puremagic.com/test-results/test.ghtml?runid=6631

You can see from the checkout log that the object files were updated, but from the dmd test run, the same test failed in the same way.

On 1/26/2011 11:19 AM, Brad Roberts wrote:
> On 1/26/2011 8:51 AM, Jonathan M Davis wrote:
>> On Wednesday 26 January 2011 04:35:13 Don Clugston wrote:
>>> On 26 January 2011 12:21, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>>> On Wednesday 26 January 2011 03:02:55 Don Clugston wrote:
>>>>> On 26 January 2011 11:17, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>>>>> On Wednesday 26 January 2011 01:58:50 Don Clugston wrote:
>>>>>>> On 26 January 2011 10:32, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>>>>>>> How else would an error be thrown?
>>>>>>>
>>>>>>> In many cases, it's thrown by hardware. The exception object is
>>>>>>> created long after the throw occurred.
>>>>>>> There are also 'foreign' exceptions, which are thrown by (say) C++.
>>>>>>>
>>>>>>> (I suspect that Linux DMD can't handle any of those -- but Windows
>>>>>>> DMD can).
>>>>>>
>>>>>> So, what exactly about that makes it a problem that the file and line number have default arguments? If it gives the arguments (like it pretty much has to be doing),
>>>>>
>>>>> No, it doesn't give the arguments. It has no way of knowing what they are (in fact, they may not even exist at all).
>>>>>
>>>>> then it doesn't use the defaults, so they don't cause any problems
>>>>>
>>>>>> there. And is it only file and line number which cause problems if they have defaults, or is it everything (e.g. Throwable next)?
>>>>>
>>>>> It's only file and line number that are a problem. next will just be null. The thing which you're maybe not understanding is that in these cases, the exception object is created when it is caught, not when it is thrown.
>>>>
>>>> Well, I certainly I have no clue about what is really going on then, and it would probably take a fair bit of discussion and/or research for me to understand. Obviously, there's stuff going on here that's at a far lower level than I'm used to dealing with.
>>>
>>> Yeah, it's a bit hairy. It took me a few weeks to work out what's going on.
>>> There's all kinds of weird stuff, where you make function calls that
>>> never return, because the stack disappears...
>>> In the end, the whole thing is an elaborate illusion that gives you a
>>> really nice model to program against.
>>> Fortunately, all of the weirdness is confined to a very small number
>>> of functions.
>>>
>>>> Regardless, is it all Throwables that have the problem, or is it just Throwable, Exception, and or Error? Throwable and Error really shouldn't be a problem, since programmers wouldn't normally be creating those (at most, they'd be creating objects derived from them), but you definitely lose something if Exception has the problem as well. And you _definitely_ lose something if _all_ Throwables have the problem. In any case, I need to know which ones are a problem if I'm going to fix them.
>>>
>>> It is only Throwable, and Error. Not anything derived from them. (Really, I think both of those should eventually become abstract classes anyway. Not right now, because compiler changes are required).
>>
>> Well, that shouldn't be much of a problem then. I really would have expected them to be abstract anyway. I'll check in a fix shortly.
>>
>> - Jonathan M Davis
> 
> Hrm.. the revert didn't make the problem go away:
> 
> http://d.puremagic.com/test-results/test.ghtml?runid=6631
> 
> You can see from the checkout log that the object files were updated, but from the dmd test run, the same test failed in the same way.

Fixed enough to not crash any more.  The problem is that while there are default args on the function, the caller is always responsible for setting up the stack correctly.  The calls to the HiddenFuncError code are all compiler generated and only generates the one original parameter right now.  So I reverted back to the version before the changes.

I don't know that we're done with this discussion.. but at least the tests are passing once again.

On Wednesday 26 January 2011 21:32:13 Brad Roberts wrote:
> On 1/26/2011 11:19 AM, Brad Roberts wrote:
> > On 1/26/2011 8:51 AM, Jonathan M Davis wrote:
> >> On Wednesday 26 January 2011 04:35:13 Don Clugston wrote:
> >>> On 26 January 2011 12:21, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> >>>> On Wednesday 26 January 2011 03:02:55 Don Clugston wrote:
> >>>>> On 26 January 2011 11:17, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> >>>>>> On Wednesday 26 January 2011 01:58:50 Don Clugston wrote:
> >>>>>>> On 26 January 2011 10:32, Jonathan M Davis <jmdavisProg at gmx.com>
wrote:
> >>>>>>>> How else would an error be thrown?
> >>>>>>> 
> >>>>>>> In many cases, it's thrown by hardware. The exception object is
> >>>>>>> created long after the throw occurred.
> >>>>>>> There are also 'foreign' exceptions, which are thrown by (say) C++.
> >>>>>>> 
> >>>>>>> (I suspect that Linux DMD can't handle any of those -- but Windows
> >>>>>>> DMD can).
> >>>>>> 
> >>>>>> So, what exactly about that makes it a problem that the file and line number have default arguments? If it gives the arguments (like it pretty much has to be doing),
> >>>>> 
> >>>>> No, it doesn't give the arguments. It has no way of knowing what they are (in fact, they may not even exist at all).
> >>>>> 
> >>>>> then it doesn't use the defaults, so they don't cause any problems
> >>>>> 
> >>>>>> there. And is it only file and line number which cause problems if they have defaults, or is it everything (e.g. Throwable next)?
> >>>>> 
> >>>>> It's only file and line number that are a problem. next will just be null. The thing which you're maybe not understanding is that in these cases, the exception object is created when it is caught, not when it is thrown.
> >>>> 
> >>>> Well, I certainly I have no clue about what is really going on then, and it would probably take a fair bit of discussion and/or research for me to understand. Obviously, there's stuff going on here that's at a far lower level than I'm used to dealing with.
> >>> 
> >>> Yeah, it's a bit hairy. It took me a few weeks to work out what's going
> >>> on. There's all kinds of weird stuff, where you make function calls
> >>> that never return, because the stack disappears...
> >>> In the end, the whole thing is an elaborate illusion that gives you a
> >>> really nice model to program against.
> >>> Fortunately, all of the weirdness is confined to a very small number
> >>> of functions.
> >>> 
> >>>> Regardless, is it all Throwables that have the problem, or is it just
> >>>> Throwable, Exception, and or Error? Throwable and Error really
> >>>> shouldn't be a problem, since programmers wouldn't normally be
> >>>> creating those (at most, they'd be creating objects derived from
> >>>> them), but you definitely lose something if Exception has the problem
> >>>> as well. And you
> >>>> _definitely_ lose something if _all_ Throwables have the problem. In
> >>>> any case, I need to know which ones are a problem if I'm going to fix
> >>>> them.
> >>> 
> >>> It is only Throwable, and Error. Not anything derived from them. (Really, I think both of those should eventually become abstract classes anyway. Not right now, because compiler changes are required).
> >> 
> >> Well, that shouldn't be much of a problem then. I really would have expected them to be abstract anyway. I'll check in a fix shortly.
> >> 
> >> - Jonathan M Davis
> > 
> > Hrm.. the revert didn't make the problem go away:
> > 
> > http://d.puremagic.com/test-results/test.ghtml?runid=6631
> > 
> > You can see from the checkout log that the object files were updated, but from the dmd test run, the same test failed in the same way.
> 
> Fixed enough to not crash any more.  The problem is that while there are default args on the function, the caller is always responsible for setting up the stack correctly.  The calls to the HiddenFuncError code are all compiler generated and only generates the one original parameter right now.  So I reverted back to the version before the changes.
> 
> I don't know that we're done with this discussion.. but at least the tests are passing once again.

Well, I'm not sure that I entirely understand what the problem is, but it sounds like the problem relates to the extern(C) functions in particular. So, perhaps all of those should be reverted. Proper D code can use the Error types directly if it likes, and then I would expect that the default arguments would work just fine. It sounds like the default arguments are causing problems in cases where what we're dealing with is on a low enough level that the normal D rules don't necessarily apply. I did verify that default arguments worked with extern(C) before checking in those changes, but apparently what I tested wasn't good enough. Perhaps it's because I then called the extern(C) functions from D rather than C or C++. That might explain why I missed it.

So, does it sound like it would just be a good idea to revert the changes on the extern(C) functions? I'd rather be safe than sorry, and while I do think that in general, it's best to have the file and line arguments for exception types have default arguments, if we're talking about low level and/or C/C++ code which is dealing with it, it might be best to just play it safe and not have the default arguments on the extern(C) functions.

- Jonathan M Davis

Jonathan M Davis wrote:
> On Wednesday 26 January 2011 21:32:13 Brad Roberts wrote:
> 
>> On 1/26/2011 11:19 AM, Brad Roberts wrote:
>> 
>>> On 1/26/2011 8:51 AM, Jonathan M Davis wrote:
>>> 
>>>> On Wednesday 26 January 2011 04:35:13 Don Clugston wrote:
>>>> 
>>>>> On 26 January 2011 12:21, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>>>> 
>>>>>> On Wednesday 26 January 2011 03:02:55 Don Clugston wrote:
>>>>>> 
>>>>>>> On 26 January 2011 11:17, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>>>>>> 
>>>>>>>> On Wednesday 26 January 2011 01:58:50 Don Clugston wrote:
>>>>>>>> 
>>>>>>>>> On 26 January 2011 10:32, Jonathan M Davis <jmdavisProg at gmx.com>
>>>>>>>>> 
> wrote:
> 
>>>>>>>>>> How else would an error be thrown?
>>>>>>>>>> 
>>>>>>>>> In many cases, it's thrown by hardware. The exception object is
>>>>>>>>> created long after the throw occurred.
>>>>>>>>> There are also 'foreign' exceptions, which are thrown by (say) C++.
>>>>>>>>>
>>>>>>>>> (I suspect that Linux DMD can't handle any of those -- but Windows
>>>>>>>>> DMD can).
>>>>>>>>> 
>>>>>>>> So, what exactly about that makes it a problem that the file and
>>>>>>>> line number have default arguments? If it gives the arguments (like
>>>>>>>> it pretty much has to be doing),
>>>>>>>> 
>>>>>>> No, it doesn't give the arguments. It has no way of knowing what they are (in fact, they may not even exist at all).
>>>>>>>
>>>>>>> then it doesn't use the defaults, so they don't cause any problems
>>>>>>>
>>>>>>> 
>>>>>>>> there. And is it only file and line number which cause problems if
>>>>>>>> they have defaults, or is it everything (e.g. Throwable next)?
>>>>>>>> 
>>>>>>> It's only file and line number that are a problem. next will just be
>>>>>>> null. The thing which you're maybe not understanding is that in these
>>>>>>> cases, the exception object is created when it is caught, not when it
>>>>>>> is thrown.
>>>>>>> 
>>>>>> Well, I certainly I have no clue about what is really going on then,
>>>>>> and it would probably take a fair bit of discussion and/or research
>>>>>> for me to understand. Obviously, there's stuff going on here that's
>>>>>> at a far lower level than I'm used to dealing with.
>>>>>> 
>>>>> Yeah, it's a bit hairy. It took me a few weeks to work out what's going
>>>>> on. There's all kinds of weird stuff, where you make function calls
>>>>> that never return, because the stack disappears...
>>>>> In the end, the whole thing is an elaborate illusion that gives you a
>>>>> really nice model to program against.
>>>>> Fortunately, all of the weirdness is confined to a very small number
>>>>> of functions.
>>>>>
>>>>> 
>>>>>> Regardless, is it all Throwables that have the problem, or is it just
>>>>>> Throwable, Exception, and or Error? Throwable and Error really
>>>>>> shouldn't be a problem, since programmers wouldn't normally be
>>>>>> creating those (at most, they'd be creating objects derived from
>>>>>> them), but you definitely lose something if Exception has the problem
>>>>>> as well. And you
>>>>>> _definitely_ lose something if _all_ Throwables have the problem. In
>>>>>> any case, I need to know which ones are a problem if I'm going to fix
>>>>>> them.
>>>>>> 
>>>>> It is only Throwable, and Error. Not anything derived from them.
>>>>> (Really, I think both of those should eventually become abstract
>>>>> classes anyway. Not right now, because compiler changes are required).
>>>>> 
>>>> Well, that shouldn't be much of a problem then. I really would have expected them to be abstract anyway. I'll check in a fix shortly.
>>>>
>>>> - Jonathan M Davis
>>>> 
>>> Hrm.. the revert didn't make the problem go away:
>>>
>>> http://d.puremagic.com/test-results/test.ghtml?runid=6631
>>>
>>> You can see from the checkout log that the object files were updated, but
>>> from the dmd test run, the same test failed in the same way.
>>> 
>> Fixed enough to not crash any more.  The problem is that while there are default args on the function, the caller is always responsible for setting up the stack correctly.  The calls to the HiddenFuncError code are all compiler generated and only generates the one original parameter right now.  So I reverted back to the version before the changes.
>>
>> I don't know that we're done with this discussion.. but at least the tests
>> are passing once again.
>> 
>
> Well, I'm not sure that I entirely understand what the problem is, but it sounds like the problem relates to the extern(C) functions in particular. So, perhaps all of those should be reverted. Proper D code can use the Error types directly if it likes, and then I would expect that the default arguments would work just fine. It sounds like the default arguments are causing problems in cases where what we're dealing with is on a low enough level that the normal D rules don't necessarily apply. I did verify that default arguments worked with extern(C) before checking in those changes, but apparently what I tested wasn't good enough. Perhaps it's because I then called the extern(C) functions from D rather than C or C++. That might explain why I missed it.
>
> So, does it sound like it would just be a good idea to revert the changes on the extern(C) functions? I'd rather be safe than sorry, and while I do think that in general, it's best to have the file and line arguments for exception types have default arguments, if we're talking about low level and/or C/C++ code which is dealing with it, it might be best to just play it safe and not have the default arguments on the extern(C) functions.
>
> 

I think it's better to figure out exactly what went wrong rather than all the guessing going on. Is it a mismatch between calling conventions between the caller and the callee? Just what instruction was the seg fault on?

On 1/26/2011 10:23 PM, Walter Bright wrote:
> 
> 
> Jonathan M Davis wrote:
>> On Wednesday 26 January 2011 21:32:13 Brad Roberts wrote:
>> 
>>> On 1/26/2011 11:19 AM, Brad Roberts wrote:
>>> 
>>> Fixed enough to not crash any more.  The problem is that while there are
>>> default args on the function, the caller is always responsible for setting
>>> up the stack correctly.  The calls to the HiddenFuncError code are all
>>> compiler generated and only generates the one original parameter right
>>> now.  So I reverted back to the version before the changes.
>>>
>>> I don't know that we're done with this discussion.. but at least the tests
>>> are passing once again.
>>> 
>>
>> Well, I'm not sure that I entirely understand what the problem is, but it sounds like the problem relates to the extern(C) functions in particular. So, perhaps all of those should be reverted. Proper D code can use the Error types directly if it likes, and then I would expect that the default arguments would work just fine. It sounds like the default arguments are causing problems in cases where what we're dealing with is on a low enough level that the normal D rules don't necessarily apply. I did verify that default arguments worked with extern(C) before checking in those changes, but apparently what I tested wasn't good enough. Perhaps it's because I then called the extern(C) functions from D rather than C or C++. That might explain why I missed it.
>>
>> So, does it sound like it would just be a good idea to revert the changes on the extern(C) functions? I'd rather be safe than sorry, and while I do think that in general, it's best to have the file and line arguments for exception types have default arguments, if we're talking about low level and/or C/C++ code which is dealing with it, it might be best to just play it safe and not have the default arguments on the extern(C) funchtions.
>>
>> 
> 
> I think it's better to figure out exactly what went wrong rather than all the guessing going on. Is it a mismatch between calling conventions between the caller and the callee? Just what instruction was the seg fault on?

I wasn't guessing, though potentially misunderstanding.  It _is_ the caller not the callee that is required to deal with all args, including optional, right?

That said, I was slightly off, but only slightly.  The compiler isn't creating the exception class directly, but indirectly by way of a runtime function call.

The compiler creates a call site like:

push object
call _d_hidden_func

in rt/dmain2.d it lands in:

extern (C) void _d_hidden_func()

That function's a tad odd.. no parameters declared, though it receives one.  It's asm code recognizes this and moves it from [E|R]AX to a local 'o'.  It then calls onHiddenFuncError(o).  That function is extern'ed at the top of the file as:

extern (C) void onHiddenFuncError(Object o);

The _real_ function is declared over in core/exception.d as:

extern (C) void onHiddenFuncError( Object o ) { ... }

That function in the big round of exception changes was changed to take additional optional parameters.  The extern declaration in dmain2.d wasn't changed, however, so the call resulted in garbage data for the new parameters.

Those are passed directly into the ctor for HiddenFuncError.  Inside the ctor for HiddenFuncError were passed to Error's ctor by way of a super(...) call.  The appropriate Error ctor passes them straight through to Throwable's ctor where they're stored.  I stopped short of finding where the bad data was used, since I was sure that the behavior was wrong. Reverting the extra parameters so that the two declarations matched and all is well with the world, or at least that corner of it.  An alternate fix might well have been to sync up the declarations, but the file and line number would have been useless anyway.  They'd always be the landing code in the rt not the point of the problem.  Not hard to fix, but would require changing dmd and the runtime api.

If you want to look at a similar case, the SwitchError handling is still broken, which is what's causing test4 to fail.
 It's the one you commented on a couple days ago.  Now that test34.d is passing due to the revert I did, the win 32 auto
tester is failing on it.  Feel free to dig into it. :)

Later,
Brad

Brad Roberts wrote:
> On 1/26/2011 10:23 PM, Walter Bright wrote:
> 
>> Jonathan M Davis wrote:
>> 
>>> On Wednesday 26 January 2011 21:32:13 Brad Roberts wrote:
>>> 
>>> 
>>>> On 1/26/2011 11:19 AM, Brad Roberts wrote:
>>>> 
>>>> Fixed enough to not crash any more.  The problem is that while there are
>>>> default args on the function, the caller is always responsible for setting
>>>> up the stack correctly.  The calls to the HiddenFuncError code are all
>>>> compiler generated and only generates the one original parameter right
>>>> now.  So I reverted back to the version before the changes.
>>>>
>>>> I don't know that we're done with this discussion.. but at least the tests
>>>> are passing once again.
>>>> 
>>>> 
>>> Well, I'm not sure that I entirely understand what the problem is, but it sounds like the problem relates to the extern(C) functions in particular. So, perhaps all of those should be reverted. Proper D code can use the Error types directly if it likes, and then I would expect that the default arguments would work just fine. It sounds like the default arguments are causing problems in cases where what we're dealing with is on a low enough level that the normal D rules don't necessarily apply. I did verify that default arguments worked with extern(C) before checking in those changes, but apparently what I tested wasn't good enough. Perhaps it's because I then called the extern(C) functions from D rather than C or C++. That might explain why I missed it.
>>>
>>> So, does it sound like it would just be a good idea to revert the changes on the extern(C) functions? I'd rather be safe than sorry, and while I do think that in general, it's best to have the file and line arguments for exception types have default arguments, if we're talking about low level and/or C/C++ code which is dealing with it, it might be best to just play it safe and not have the default arguments on the extern(C) funchtions.
>>>
>>> 
>>> 
>> I think it's better to figure out exactly what went wrong rather than all the guessing going on. Is it a mismatch
>> between calling conventions between the caller and the callee? Just what instruction was the seg fault on?
>> 
>
> I wasn't guessing, though potentially misunderstanding.  It _is_ the caller not the callee that is required to deal with all args, including optional, right?
>
> That said, I was slightly off, but only slightly.  The compiler isn't creating the exception class directly, but indirectly by way of a runtime function call.
>
> The compiler creates a call site like:
>
> push object
> call _d_hidden_func
>
> in rt/dmain2.d it lands in:
>
> extern (C) void _d_hidden_func()
>
> That function's a tad odd.. no parameters declared, though it receives one.  It's asm code recognizes this and moves it from [E|R]AX to a local 'o'.  It then calls onHiddenFuncError(o).  That function is extern'ed at the top of the file as:
>
> extern (C) void onHiddenFuncError(Object o);
>
> The _real_ function is declared over in core/exception.d as:
>
> extern (C) void onHiddenFuncError( Object o ) { ... }
>
> That function in the big round of exception changes was changed to take additional optional parameters.  The extern declaration in dmain2.d wasn't changed, however, so the call resulted in garbage data for the new parameters.
>
> Those are passed directly into the ctor for HiddenFuncError.  Inside the ctor for HiddenFuncError were passed to Error's ctor by way of a super(...) call.  The appropriate Error ctor passes them straight through to Throwable's ctor where they're stored.  I stopped short of finding where the bad data was used, since I was sure that the behavior was wrong. Reverting the extra parameters so that the two declarations matched and all is well with the world, or at least that corner of it.  An alternate fix might well have been to sync up the declarations, but the file and line number would have been useless anyway.  They'd always be the landing code in the rt not the point of the problem.  Not hard to fix, but would require changing dmd and the runtime api.
>
> If you want to look at a similar case, the SwitchError handling is still broken, which is what's causing test4 to fail.
>  It's the one you commented on a couple days ago.  Now that test34.d is passing due to the revert I did, the win 32 auto
> tester is failing on it.  Feel free to dig into it. :)
>
> 

Ok, that's a great analysis. Here is what is going on from the compiler perspective. The compiler replaces addresses of virtual functions in the vtbl[] with &_d_hidden_func. The point is so that an exception can be thrown for a hidden function. The only argument that is guaranteed to be passed is the object reference as the first parameter.

If more parameters are desired for onHiddenFuncError(), they must be added by _d_hidden_func. There is no way for _d_hidden_func to get the file/line from whence it came.