I agree this condition makes no sense. Whether implicit conversions are enabled or not has no bearing on eta expansion.

EDIT: it looks like it's checking, in a pretty roundabout way, that we're not inside a pattern:

|    |    |    |-- fuzzy_df1.Fuzz : pt=Int PATTERNmode (site: value x$1 in A) enrichment only
|    |    |    |    |-- `fuzzy_df1` EXPRmode-POLYmode-QUALmode (site: value x$1 in A) enrichment only

"enrichment only" is our way of saying full on implicit search is disabled (conversions still allowed)

        def cantAdapt =
          if (mode.inQualMode) UnstableTreeError(tree)
          else MissingArgsForMethodTpeError(tree, meth)

seems like the way to go EDIT: not

It is kind of suspicious we are not getting an error from stabilize, but this seems like a move in the right direction. Maybe leave that as a TODO?

ok, so pulling on that thread some more -- pardon the stream of consciousness review -- but it seems like we need to keep pulling.

What should the error be in the following snippet?

  class Fuzzy { val Fuzz = 1 }
  def fuzzy_df1(x: Int): Fuzzy = new Fuzzy
  var z = fuzzy_df1.Fuzz

I say it should be the current one:

missing argument list for method fuzzy_df1
Unapplied methods are only converted to functions when a function type is expected.
You can make this conversion explicit by writing `fuzzy_df1 _` or `fuzzy_df1(_)` instead of `fuzzy_df1`.

stability is not the issue here. It's also weird to complain that Fuzz is not a member of the method type (x: Int): Fuzzy since methods are not values and thus cannot have members (that's why they are eta-expanded to functions, which are values.)

That error sounds reasonable. My patch doesn't change it in that case. Perhaps cantAdapt should always be MissingArgsForMethodTypeError, after all.

It is kind of suspicious we are not getting an error from stabilize, but this seems like a move in the right direction.

The instability errors that I based my guess on are from stabilize, but qualifiers of patterns aren't typed in PATTERNmode so it doesn't complain there.

Putting on my end-user hat, I see:

scala> (??? : Any) match { case Foo.Bar.Baz => }
<console>:13: error: missing argument list for method Bar in object Foo
Unapplied methods are only converted to functions when a function type is expected.
You can make this conversion explicit by writing `Bar _` or `Bar(_)` instead of `Bar`.

and I'm not sure how helpful of an error message this is:

scala> (??? : Any) match { case Foo.Bar.Baz _ => }
<console>:14: error: '=>' expected but '_' found.
(??? : Any) match { case Foo.Bar.Baz _ => } 
                                     ^

scala> (??? : Any) match { case Foo.Bar.Baz(_) => }
<console>:15: error: stable identifier required, but Foo.Bar found.
       (??? : Any) match { case Foo.Bar.Baz(_) => }
                                    ^

The latter one was also a crasher before this patch.

The "missing argument list for method Bar in object Foo" is reasonable; perhaps MissingArgsForMethodTpeError could give better advice if we get to cantAdapt in PATTERNmode? I'm rightly not allowed to write user-facing messages at my job, but something like "Unapplied methods cannot be used as patterns. If you meant to define an extractor, Foo should be a value with an unapply or unapplySeq method."

qualifiers of patterns aren't typed in PATTERNmode so it doesn't complain there.

Spot on, I think that points in the direction of a better error message. Maybe we should track that the context is typing a pattern (looks like we have isTyperInPattern, which would be better implemented as a context mode, similar to PatternAlternative)? In fact, context.implicitsEnabled seems to be doing just that, albeit in a pretty roundabout way (we type patterns with enrichment enabled, but general implicits turned off)

Perhaps cantAdapt should always be MissingArgsForMethodTypeError, after all.
I tried that as well, but it looks like we need something more subtle.

I'll try to sit down later this week and add some more concrete suggestions.

Sheesh. The hole just keeps on going.

scala> def Foo(x: Int) = x
Foo: (x: Int)Int

scala> object Bar { def Bip(x: Int) = x }
defined object Bar

scala> (??? : Any) match { case Foo => }
<console>:13: error: stable identifier required, but Foo found.
       (??? : Any) match { case Foo => }
                                ^

scala> (??? : Any) match { case Foo(_) => }
<console>:13: error: not found: value Foo
       (??? : Any) match { case Foo(_) => }
                                ^

scala> (??? : Any) match { case Bar.Bip(_) => }
<console>:13: error: method Bip is not a case class, nor does it have an unapply/unapplySeq member
       (??? : Any) match { case Bar.Bip(_) => }
                                    ^

scala> (??? : Any) match { case Bar.Bip => }
<console>:13: error: stable identifier required, but Bar.Bip found.
       (??? : Any) match { case Bar.Bip => }
                                    ^

It's a nice little tour of all sorts of typer errors. I'm kind of leaning, now that I think about it, in the direction of the CaseClassConstructorError we get in the Bar.Bip case, but it would be kinda cool if the same one showed up for the Foo(_) case (I can't see why they're different, from an error perspective). The third error at least points in the direction of what's wrong;

The instability one gets less and less justifiable the more I look at it.

Maybe just:

scala> (??? : Any) match { case Bar.Bip => }
<console>:13: error: method `Bar.Bip` cannot be used as an identifier pattern;
identifier patterns must refer to values.
       (??? : Any) match { case Bar.Bip => }
                                    ^

scala> (??? : Any) match { case Bar.Bip(_) => }
<console>:13: error: method Bar.Bip cannot be used as an extractor pattern;
perhaps you meant to define a value `Bip` with an `unapply` or `unapplySeq` method?
       (??? : Any) match { case Bar.Bip(_) => }
                                    ^

Nice exploration :-) Agreed on stability -- not really the best thing to complain about here. Oh scalac.

For (??? : Any) match { case Foo => }, the fix could also be turning Foo into a val.

I can't think of a reason why case Foo(_) and case Bar.Bip(_) should result in different errors. I like your suggested rewordings for both errors.

Great job, I wanted to find some time to fix this issue. Currently, def F(k:Int)=k;val F.K = () throws a NullPointerException.