[llvm-commits] [PATCH] Newest LandingPad Patch

[Bill Wendling]

On Aug 8, 2011, at 1:25 AM, John McCall wrote:

> On Aug 8, 2011, at 1:13 AM, Bill Wendling wrote:
>> On Aug 8, 2011, at 12:03 AM, John McCall wrote:
>>> Correct.  The first filters out exceptions they aren't a and aren't b and aren't c, and the second trips on exceptions if they aren't a, or they aren't b, or they aren't c.
>>> 
>>> Combining filters is also impossible because of the semantics of std::unexpected, which is allowed to change the exception type to satisfy the filter.
>>> 
>> Why does this prohibit combining filters? Or, I guess more to the point, what do you mean by combining the filters? Are you suggesting that we cannot inline a function with an exception specification into another function with a different exception specification?
> 
> No, that's not what I meant.  What I mean is that, conceptually, filters always apply in the order that an exception would propagate through them, and there's a fallback mechanism for changing exception types, so while there are rules you can use to optimize filters, they're somewhat complex.
> 
> Basically, it is legal to turn this:
>  filter a, b
>  filter a, b
> into this:
>  filter a, b
> 
> And it is legal to turn this:
>  filter a
>  filter a, b
> into this:
>  filter a
> 
> But it is not legal to turn this:
>  filter a, b
>  filter a
> into this:
>  filter a
> 
> Fortunately, you can just ignore all that for now. :)  Just make sure that the representation is somehow capable of listing any number of exception types per filter, including zero.
> 
Okay, grand! Thanks for the clarification. I was hoping it wasn't what I wrote, because that would be brutal. :-)

-bw