non-informative error message for a `transparent` soft keyword with multiple new lines after it

[unkarjedy]

Compiler version

3.0.0-RC1

Minimized code

def transparent = println("transparent method called")

transparent
println()
inline def f1 = 1

transparent
inline def f2 = 2

transparent
trait T1

transparent

inline def f3 = 3

transparent

def f4 = 4

transparent

trait T2

Output

Ther actually IS "start of definition" though the error says that there is no

Expectation

More informative message? (maybe better parsing? not sure)

[odersky]

If there are multiple newlines after transparent it's an identifier, not a soft keyword.

[unkarjedy]

@odersky
from https://dotty.epfl.ch/docs/reference/soft-modifier.html

A soft modifier is treated as potential modifier of a definition if it is followed by a hard modifier or a keyword combination starting a definition (def, val, var, type, given, class, trait, object, enum, case class, case object). Between the two words there may be a sequence of newline tokens and soft modifiers.

Which contradicts to:

If there are multiple newlines after transparent it's an identifier, not a soft keyword.

Also, if so, why the compiler then says "expected start of definition" and doesn't treat transparent as a function call at those places?

object A {
  def transparent: Int = {
    println("transparent method called")
    42
  }

  transparent
  println()

  transparent
  inline def f1 = 2

  transparent

  inline def f2 = 2
  
  transparent

  def f3 = 2
}

It seems that implementation should be patched in any case.
And specification should probably also be reviewed.

[som-snytt]

Thanks, unkarjedy.

I had to re-read the spec (both of them). All the [nl] vs {nl} vs nl not enabled is tricky. So glad it usually just works.

I see that the language about "sequence of newline tokens and soft mods" could be misconstrued as "arbitrary sequence". Probably it just means they can be "stacked".

I agree intuitively that if transparent is not taken softly as a keyword, it must be an ordinary identifier.

Here, transparent<nl><nl> is taken as a hard error, apparently.

As an aspirational footnote, it would be nice to visualize nl insertion, the way IDEs will make whitespace visible.

It's worth adding that "people don't write code like this", except when they are in the middle of an edit. Extra feedback might be helpful or annoying, depending on personal preferences.

[unkarjedy]

@som-snytt

So are you implying that we should leave the compiler implementation & specification as is, without any changes?

It's worth adding that "people don't write code like this", except when they are in the middle of an edit

I agree that probability to see such code is low.
But as I see it it's now about "being in the middle of an edit"
The issue can be observed whenever someone chooses to use some soft-modifier as a declaration name, use it somewhere (e.g in some DSL, IDK...) and then decides to add some definition below the usage
(I use compiler-based highlighting in the example, so the errors come from the compiler)

[som-snytt]

I intended to agree with you, and say the "orphan" transparent should bind to your definition in scope. (That is my intuition, without looking closely yet at the mechanics.)

I also think the phrase "sequence of newlines" you pointed out in the reference should be more specific (and in the grammar). However, although I periodically re-read the rules about newlines, I never retain them; I rely just on common practices or style.

[unkarjedy]

Ok, why I am asking is that I am trying to understand whether it is ok to continue keeping this ticket as "Closed" if any clarifications in the spec are going to be made

[odersky]

@unkarjedy I think you are right, it needs a clarification or a software fix.

Maybe it's simplest to try a software fix to accept these as soft modifiers.