[llvm-commits] [PATCH] Newest LandingPad Patch

[John McCall]

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.

John.