[LLVMdev] RFC: Exception Handling Rewrite
Bill Wendling
wendling at apple.com
Tue Aug 2 18:01:29 PDT 2011
On Aug 2, 2011, at 4:43 PM, John McCall wrote:
> On Aug 2, 2011, at 10:28 AM, Duncan Sands wrote:
>>>>> Is it intended that "cleanup ty_1, ty_2" potentially be different to
>>>>> "cleanup ty_1 cleanup ty_2"? Perhaps this is useful for funky personality
>>>>> functions.
>>>>>
>>>> Yeah. One can basically interleave the catches and filters. But having two catch or two filter clauses in a row should be semantically the same as the clauses being merged into one. (E.g., your examples would be equivalent.)
>>>
>>> Let me rephrase the question then. Why not make the grammar be either:
>>>
>>>>>> <clause> :=
>>>>>> cleanup
>>>>>> | catch<ty_1>
>>>>>> | filter<ty_1>
>>>
>>> .. forcing "catch" or "filter" before each entry. If you don't like that, why not make the grammar be something like:
>>>
>>>>>> %res = landingpad<somety> personality<ty> <pers_fn> (catch<ty>+)? (filter<ty>+)?
>>>
>>> Is there anything specific about the ordering of catch or filter clauses that affect semantics? If so, the first alternative seems cleaner. If not, the second does.
>>
>> yes there is something about the order :) When front-ends output code, all
>> catches come before filters, but after inlining you can get: catches, filters,
>> catches, filters etc and this ordering needs to be preserved. Also, filters
>> are different from catches: filter ty_1, ty_2, ..., ty_N matches any exception
>> that would not be caught by any of ty_1, ty_2, ..., ty_N. This is quite
>> different to filter ty_1, filter ty_2, ..., filter ty_N. For example, suppose
>> you throw ty_2. Then the filter ty_1, ty_2, ..., ty_N wouldn't match that,
>> but filter ty_1 would.
>>
>> So filter ty_1, ..., ty_N makes sense; but I don't think catch ty_1, ..., ty_N
>> makes sense.
>
> Agreed. Other notes: a zero-type filter is meaningful (and pretty
> common — it's the result of 'throw()'), but the ordering of the cleanup
> bit is not, so I would suggest this grammar:
>
> Instruction ::= 'landingpad' Type 'personality' TypeAndValue 'cleanup'? LandingPadClause*
> LandingPadClause ::= 'catch' TypeAndValue
> LandingPadClause ::= 'filter' TypeAndValue*
>
*smacks forehead* Duncan and John are exactly right with regards to filters. In my zeal today, I took out the code that would parse the 'filter' clause correctly. I'll add that back in and submit a corrected patch.
-bw
More information about the llvm-dev
mailing list