New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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 #5044

Closed
scabug opened this Issue Sep 29, 2011 · 7 comments

Comments

Projects
None yet
2 participants
@scabug
Copy link

scabug commented Sep 29, 2011

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

This comment has been minimized.

Copy link
Author

scabug commented Sep 29, 2011

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

This comment has been minimized.

Copy link
Author

scabug commented Sep 29, 2011

@harrah said:
A bit simpler test case:

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

This comment has been minimized.

Copy link
Author

scabug commented Oct 1, 2011

@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

This comment has been minimized.

Copy link
Author

scabug commented Oct 1, 2011

@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

This comment has been minimized.

Copy link
Author

scabug commented May 7, 2012

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

@scabug

This comment has been minimized.

Copy link
Author

scabug commented May 16, 2012

@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 scabug closed this May 16, 2012

@scabug

This comment has been minimized.

Copy link
Author

scabug commented May 19, 2012

@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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment