[D-runtime] win32 regression in exception handling

[Brad Roberts]

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.