Uploaded image for project: 'Scala Programming Language'
  1. Scala Programming Language
  2. SI-5044

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

    Details

      Description

      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(">")
        }
      }
      

        Attachments

          Issue Links

            Activity

            Hide
            harrah Mark Harrah added a comment -

            A bit simpler test case:

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

            Show
            harrah Mark Harrah added a comment - A bit simpler test case: val a = Option(x = "") val x = println(a)
            Hide
            extempore Paul Phillips added a comment -

            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.

            Show
            extempore Paul Phillips added a comment - 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.
            Hide
            extempore Paul Phillips added a comment -

            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.

            Show
            extempore Paul Phillips added a comment - 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.
            Hide
            retronym Jason Zaugg added a comment - - edited

            Pretty close cousin of SI-4928

            Show
            retronym Jason Zaugg added a comment - - edited Pretty close cousin of SI-4928
            Hide
            rytz Lukas Rytz added a comment - - edited

            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

            Show
            rytz Lukas Rytz added a comment - - edited 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
            Hide
            rytz Lukas Rytz added a comment -

            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.
            

            Show
            rytz Lukas Rytz added a comment - 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.

              People

              • Assignee:
                rytz Lukas Rytz
                Reporter:
                yaroslav ulanovych Yaroslav Ulanovych
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: