Discourage default arg for extension receiver

[som-snytt]

Fixes #12460

I shied away from making it an error, as that is a language change that violates the rule that extension methods are ordinary methods. There are other restrictions, but an extension always allows explicit invocation m()(x) that could leverage a default.

The caret is wrong on the second test case (todo). Edit: span of default getter was union of first parameter and the param RHS, so that the synthetic position of the getter symbol was a point at the first parameter. Now the getter tree gets the span of the RHS. (That span is non-synthetic, but the definition is still synthetic. The name pos of a synthetic is the point.)

[som-snytt]

Minor edit overlap with #22502

[KacperFKorban]

nit: Can you move that into a local function? The logic might be slightly clearer then.

[som-snytt]

also leverage HasDefaultParams

[KacperFKorban]

question: I think that this message might be confusing, since it's technically false. They don't have to be invoked as a selection.
I can agree on adding a warning here, since it in most cases it's undesired to have a default value for a receiver of an extension method, but I we should make the message conditional -- e.g. When invoking an extension method as a selection, the receiver cannot be omitted.

[Sporarum]

I think this change makes the code harder to read, and harder to expand later

In the case of methods with multiple lambda parameters, it is advised to stick to braced code

[som-snytt]

It makes it clear that there are two arg lists consisting of a simple lambdas.

What looks new is that we know the expression continues. This is a feature.

It's an anti-feature to expect to expand the code in these blocks, which would turn them from merely ugly to inscrutable.

Alternatively

    def getterParamss(n: Int): List[ParamClause] =
      inline def m = mapParamss(takeUpTo(paramssNoRHS, n)):
        tparam => dropContextBounds(toMethParam(tparam, KeepAnnotations.All))
      m:
        vparam => toMethParam(vparam, KeepAnnotations.All, keepDefault = false)

I don't agree with your premise, but I'll revert it on the basis that it is not my code.

[Sporarum]

I was going to ask about the following case:

extension (x: => Any)
  def hello = "hello"

{println("print me")}.hello

But it seems this would not necessarily be a problem:

class Foo(y: Int):
  inline def hello = "hello"

lazy val x = 
  println("x")
  Foo(1)

x.hello // returns "hello" without printing "x"

Edit: Or maybe yes ?

class Foo(y: Int):
  inline def hello = "hello"

{println("x"); Foo(1)}.hello // returns "hello" AND prints "x"

[som-snytt]

I think the warning is a bit dubious, but maybe the question is: What were they trying to accomplish?

I might have a "zero" value to invoke an extension, such as NoSymbol.debugName but maybe I don't and need to debugName() without having to pass in a sentinel value.

I added the sentence from the "nullification" message, which may also be dubious advice:

  | An extension method can be invoked as a regular method, but if that is the intended usage,
  | it should not be defined as an extension.

I previously saw a comment about evaluation order with by-name param, but it's not stranger than LazyList.

extension (x: => Any) def hello = "hello"

@main def test = println:
  def x = println("ugh")
  def y: LazyList[Unit] = x #:: y
  (x.hello, y) // (hello,LazyList(<not computed>)) but no ugh

but I agree it should be possible to write extensions without getting tricky.

[KacperFKorban]

Looks good now, added a small comment about the warning message.
I think that the the by-name receiver isn't in the scope of this PR and #17321 should probably address that issue.

[KacperFKorban]

nit: I think that the newline makes the message hard to parse now, since I first read only the first line, which is grammatically correct – Although extensions are ordinary methods, when they are invoked as a selection,

[som-snytt]

It's not a complete sentence. However, I have rephrased to use no clauses.