The result of a method, taking an object of some case class, can not be assigned to a variable with the name as the name of any field of that class

[scabug]

case class A(
  id: Int = 0,
  name: String = "",
  age: Int = 20
)

object Tmp {

  def m(a: A) = ""
  
  def main(args: Array[String]) {
    val a = A(name = "")
    val name = Tmp.m(a) // compiler error: recursive value a needs type
    println(">")
  }
}

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-5044?orig=1
Reporter: Yaroslav Ulanovych (yaroslav ulanovych)
Affected Versions: 2.9.1
See #4928

[scabug]

@harrah said:
A bit simpler test case:

val a = Option(x = "")
val x = println(a)

[scabug]

@paulp said:
Heh, simpler for those who know off the top of their head what the name of the parameter to Option.apply is. Fortunately that is the relevant audience.

[scabug]

@paulp said:
I say that of course because this too gives the very same error:

val a = Option(y = "")
val y = println(a)

Not like anyone can know a priori one should work and one shouldn't.

[scabug]

@retronym said (edited on May 7, 2012 4:01:53 PM UTC):
Pretty close cousin of #4928

[scabug]

@lrytz said (edited on May 19, 2012 12:26:27 PM UTC):
There really is a cyclic dependency: when type checking the application, we need to type-check the named argument to test if it's a valid assignment expression.

So I think the error is not wrong. Giving an explicit type either to "a" or "y" is the correct way of fixing the code.

However the error message is not very explicit about what to do. This is done in [https://github.com/scala/scala/commit/4669ac180e58daf97ac7f73af4622434b439631d]

[scabug]

@lrytz said:
related discussion: [https://github.com/lrytz/scala/commit/2ab4733e381f2e5df376b785bba9b759476e9706]

adriaanm
is there potential for false positives here? @hubertp, what do you think?


lrytz
my hope is that the reporter only counts errors that are actually reported.
the long term solution here would be to make sure "silent" is actually silent. asking the compiler if something type-checks should be one of the services that the compiler provides.


adriaanm
right, that sounds like a bug in silent
I was also worried about other errors being reported, not the one you're looking for.
Maybe you can look into the buffer for the specific error that's relevant here? Or maybe that could be another nice feature.


lrytz
not sure if reporters store the errors. i know that contexts do, but we don't have access to the context here (well, not to the one in which the error is reported, this one stems from a lazy type).
i'm not too worried because cyclic references are the only kind of errors that are not silenced properly. if you get a cyclic reference type-checking "a = expr", we hope that it's related to "a". i agree it could be unrelated in principle.


hubertp
cyclic errors are not covered by the silent by design. Reporter only counts (or at least should) the errors that are reported, that's correct.
It seems that the best way would be to always catch the cyclic error, log it in the buffer and re-throw, though I don't know what would be the performance impact (probably negligible since it only happens on a real error).


lrytz
If "silent" would actually throw the cyclic reference, that solve my problem here. but what happens is that I call "silent(typed(someTree))", and somebody catches and reports the cyclic reference.


adriaanm
so, maybe we can have a flag like reportAmbiguous that allows us to switch between those behaviours?
although I should add that boolean flags are bad according to some :-)

hubertp
I think there are too many flags around already. I will have a look and see why is it reported in the first place.