Locally is inline

[som-snytt]

The two usages of locally in the code base are actually just to parenthesize if-else in a boolean expression.

Because locally is not inline, that requires boxing the boolean, which is unused.

Inlining locally makes using it guilt-free. The signature is not changed here. To preserve bincompat, it overrides a non-inline method.

This commit fixes a doc typo and makes a boolean expression more readable with leading infix operators. Normally leading infix is requested during code review, but this was after a round of edits. Here, it makes a difference to help distinguish the if conditional from the then result expression.

Also fix the tests that fail on current JVM. It is locally annoying and a time waste at 666ff49.

[sjrd]

Unfortunately, that is not backward binary compatible.

Fortunately, it shouldn't matter, because the JIT can eliminate it.

[som-snytt]

Ah yes. If I'm unable to add it to compiletime inlining, I'll change the usages to proper parens. Or, add it to dotc.util. Thanks @sjrd !

Edit: I noticed one weird trick --

[hamzaremmal]

We had a chat at some point at EPFL about potentially having an annotation to require the method to remain in the binary. I would hold on doing such acrobatics until the final decision about this.

[som-snytt]

I looked at publicInBinary (which would be reasonable) or special-casing locally in Inlines, but this works today and is an insignificant delta.

[som-snytt]

cherry-picked @elidable(0) from another PR.

[som-snytt]

I have already contributed "ignore line numbers in stack traces of tests" in another PR that is waiting patiently on the queue.

Failed to evaluate macro annotation '@crash'.
  Caused by class scala.NotImplementedError: an implementation is missing
    scala.Predef$.$qmark$qmark$qmark(Predef.scala:388)
    crash.transform(Macro_1.scala:7)