Warn if name of empty template has trailing colon

[som-snytt]

Fixes #16072
Fixes #18020

Warn to guard against colon fusion in object x_: and def x_: String.

Indent warning is made awesome.

[som-snytt]

Note that it's less helpful if scanner issues the indent warning "out of order".

-- Warning: tests/warn/i16072.scala:4:2 --------------------------------------------------------------------------------4 |  def x = 1 // warn too far right
  |  ^
  |  Line is indented too far to the right, or a `{` or `:` is missing
-- [E222] Syntax Warning: tests/warn/i16072.scala:3:7 ------------------------------------------------------------------3 |object Hello_: // warn colon in name without backticks because the body is empty
  |       ^^^^^^^
  |       name `Hello_:` should be enclosed in backticks

Must follow up givens and enums.

[som-snytt]

My first swing from Dec 2022 was more direct:

     def checkNextNotIndented(): Unit =
-      if in.isNewLine then
+      if testNextNotIndented() then
+        warning(em"Line is indented too far to the right, or a `{` or `:` is missing", in.next.offset)
+
+    def testNextNotIndented(): Boolean =
+      in.isNewLine && {
         val nextIndentWidth = in.indentWidth(in.next.offset)
-        if in.currentRegion.indentWidth < nextIndentWidth then
-          warning(em"Line is indented too far to the right, or a `{` or `:` is missing", in.next.offset)
+        in.currentRegion.indentWidth < nextIndentWidth
+      }

+    // Catch inadvertent fusion of punctuation as operator char (name_:)
+    private def checkSuspiciousColon(name: Name, offset: Offset): Unit =
+      if name.endsWith(":") && testNextNotIndented() then
+        warning(em"name ends in `:` before indented line", offset-1)
+

     def classDef(start: Offset, mods: Modifiers): TypeDef = atSpan(start, nameStart) {
-      classDefRest(start, mods, ident().toTypeName)
+      val name = ident()
+      checkSuspiciousColon(name, nameStart)
+      classDefRest(start, mods, name.toTypeName)
     }

[som-snytt]

I wonder how wedded folks are to forms of quote. I like the idea of backticks because of markdown, but the char literal printed by showToken seems more natural. I would accept backticks for user identifiers, but token ticks for tokens.

Welcome to Scala 3.8.0-RC1-bin-SNAPSHOT-nonbootstrapped-git-d394833 (23.0.2, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.

scala> locally {
     |     val x = 42
     |   val y = 27
     | }
1 warning found
-- [E223] Syntax Warning: ------------------------------------------------------
3 |  val y = 27
  |  ^
  |  Line is indented too far to the left, or a '}' is missing
  |
  | longer explanation available when compiling with `-explain`

scala>
➜  snips scala-cli repl --server=false -S 3.7.2
Welcome to Scala 3.7.2 (23.0.2, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.

scala> locally {
     |     val x = 42
     |   val y = 27
     | }
1 warning found
-- Warning: --------------------------------------------------------------------
3 |  val y = 27
  |  ^
  |  Line is indented too far to the left, or a `}` is missing

[som-snytt]

Why was the information-rich comment too verbose?

See below.

Why was the ticket worth tackling?

If it surprises keynmol, it can surprise any of us. The syntax is a mild language wart but easy enough to compensate for (by linting). (Arguably, people should be persuaded not to give underscore special meaning as a leading or trailing character in a name. For all the reduction in underscore semantics, it is still fundamental to operator names; it is not farfetched to suggest it should be discouraged for other snake purposes, in the absence of backticks, just like embedded dollar.) (Compare making underscore no longer available as an identifier.)

How I fixed it

My first attempt was to consider any such name, or such a name followed by indentation. For context, however, it's simpler to query whether the template has a body; I think #16072 (comment) by abgruszecki suggested it to me.

The improvement for def f String = "" was suggested on the ticket by dwijnand.

Why is this PR worth reviewing?

There is no syntax change, but only a warning for the two gotchas. The change is confined to the parser.

If I spend another hour on it, I'll add dwijnand's idea to split the unintended identifier in def s_: String = "" (with a warning).

What's the worse that could happen?

TBD

[som-snytt]

Indent warning is made awesome --> "awesomaticized".

Rebased. Updated check file for change in error id, but dropped the last commit as previous research.