Currently, FunctionAttrs treats landingpads as non-throwing, and will infer nounwind for functions with landingpads (and without something like resumes that continue unwinding). There are two problems with this:
- Non-cleanup landingpads with catch/filter clauses do not necessarily catch all exceptions. Unless there are catch ptr null or filter [0 x ptr] zeroinitializer clauses, we should assume that we may unwind past this landingpad. This seems like an outright bug.
- Cleanup landingpads are skipped during phase one unwinding, so we effectively need to support unwinding past them. Marking these nounwind is technically correct, but not compatible with how unwinding works in reality.