Better handling of multiple exceptions for saferExceptions

[prolativ]

• Generate a single accumulated CanThrow capability for multiple catch cases in a try
• Allow parentheses around exceptions alternatives in throws clauses

Fixes #13816

[prolativ]

@odersky could you have a look at the PR?

[odersky]

What about this scenario?

def foo() throws E1 | E2 = ...

try
  try foo()
  catch case ex: E1 => ...
catch case ex: E2 => ...

That should compile. Does it?

[odersky]

It turns out that an = in a for expression is horribly expensive, so it's actually better to do pat.tpe.widen twice.

[odersky]

Why not:

if caughtExceptions.isEmpty then expr
else
  val capabilityProof = caughtExceptions.reduce(OrType(_, _, true))
  ...

[prolativ]

Catching multiple exceptions in nested try blocks does work in general. I'll add an explicit test for that.
The only corner case is when the capability is declared with (using CanThrow[Ex1 | Ex2])
then

  catch
    case _: Ex1 =>
    case _: Ex2 =>

will work (which is already an improvement when compared to the current state) but

    catch
      case _: Ex1 =>
  catch
    case _: Ex2 =>

will fail but this doesn't work without my changes either so there's no regression. Also the docs explicitly say that (using CanThrow[E1 | E2]) syntax might cause some problems so it's better to use any of the alternative syntaxes.
We might try to improve this somehow by one of the following:

1. Introducing a generic mechanism for merging capabilities (this would probably require quite a lot of research)
2. Improving the desugaring of nested try blocks so that

try
  try
    foo()
  catch
    case _: Ex1 =>
  catch
    case _: Ex2 =>

gets desugared to

try
  erased given CanThrow[Ex2] = ???
  try
    erased given CanThrow[Ex1 | Ex2] = ???
    foo()
  catch
    case _: Ex1 =>
  catch
    case _: Ex2 =>

instead of

try
  erased given CanThrow[Ex2] = ???
  try
    erased given CanThrow[Ex1] = ???
    foo()
  catch
    case _: Ex1 =>
  catch
    case _: Ex2 =>

(1) would solve both the problem that (2) fixes and the corner case described in the docs when someone tries to call a method defined with a merged capability(using CanThrow[Ex1 | Ex2]) from a method with independent capabilities (using CanThrow[Ex1], CanThrow[Ex2]).

When I think about it now, (2) shouldn't be too difficult to implement but still this could be done in a separate PR.

[odersky]

The only corner case is when the capability is declared with (using CanThrow[Ex1 | Ex2])
then

what if it is declared as throws Ex1 | Ex2 (as in my example). Would that not be the same?

[prolativ]

A throws Ex1 | Ex2

desugars to

A $throws Ex1 $throws Ex2

Which would effectively work like

(using CanThrow[Ex1])(using CanThrow[Ex2]): A

in signatures of methods, not like

(using CanThrow[Ex1 | Ex2]): A

[odersky]

Ah yes, that answers it. Thanks!

So I think except for the other minor remarks, LGTM

[prolativ]

Reworks done. I also slightly improved the implicitNotFound message as I was often confused with the previous one.

[prolativ]

@odersky can we get this merged?

[odersky]

Yes, LGTM.