Warn on misleading indentation in single-case catch

[odersky]

Fixes #14721

Surprisingly, caught two instances in the compiler code base itself.

[som-snytt]

Make that three.

Error:  -- Error: /__w/dotty/dotty/compiler/test/dotty/tools/repl/ShadowingTests.scala:36:4 
Error:  36 |    assert(Files.isDirectory(subdir), s"failed to create shadowed subdirectory $subdir")
Error:     |    ^
Error:     |misleading indentation: this expression forms part of the preceding catch case,
Error:     |it should be indented for clarity.

Are we sure a warning is sufficient punishment? It could say something more humiliating, or maybe just sound mad.

Edit: I don't actually want to keep people from the indentation of their choice, if it parses. Except for scaladoc comments, for comments my thinking is absolutely rigid.

[griggt]

Wait, I believe my intention there was to swallow the FileAlreadyExistsException, not for the assert to be the body of the catch ...

[odersky]

OK, fixed. Goes to show that this really is a dangerous trap.

Can we make it an error? I don't see how without undermining fundamental assumptions how the parser works. According to the syntax we need an Expr and that's what we can parse. Rejecting it would mean we throw aspects which are outside the context-free syntax into the parsing algorithm.

[som-snytt]

No wait, it's asserting that the existing thing is a dir, right? If createDir succeeds, it better be a dir.

[som-snytt]

One way to clarify the syntax is to require the expr to begin on the same line as the arrow. So the arrow could move to the following line.

[odersky]

In fact the warning occurrences in the backend were also assuming an empty
catch handler. I changed them to do the right thing, and fixed the warning message
to point out this possibility.

[odersky]

@som-snytt I think you are right for ShadowingTests. The assert really is meant as a handler. @griggt can you confirm?

[griggt]

I'm almost certain that when I wrote it I meant for the catch handler to be empty. But in this case it works either way.

[som-snytt]

In fact, we need more forms of syntax that work either way. If Booleans worked either way, we'd never take the wrong branch.

[som-snytt]

Why isn't

catch case K0 =>
case K1 =>

equivalent to normal syntax, except that it is ugly? Then normal indentation rules apply to

case case K0 =>
  something

without further ado.

[odersky]

Why isn't

catch case K0 =>
case K1 =>

equivalent to normal syntax, except that it is ugly?

What would the context free syntax be to support that? We can't just parse the way we like, it has to be backed by context-free syntax rules.

[sjrd]

This seems to be useless/irrelevant.