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

regression in overriding methods with default arguments

    Details

      Description

      This compiles under 2.9.1, but under trunk:

      abstract class FileOps {
        def withLock[R](start: Long = 0): Option[R]
      }
       
      trait DefaultFileOps {
        self: DefaultPath =>
        
        override def withLock[R](start: Long = 5): Option[R] = None
      }
       
      class DefaultPath extends FileOps with DefaultFileOps { }
      

      bip.scala:11: error: overriding method withLock$default$1 in class FileOps of type [R]=> Long;
       method withLock$default$1 in trait DefaultFileOps of type [R]=> Long needs `override' modifier
      class DefaultPath extends FileOps with DefaultFileOps { }
            ^
      one error found
      

        Attachments

          Activity

          Hide
          extempore Paul Phillips added a comment -

          Caused by me in r25709.

          Show
          extempore Paul Phillips added a comment - Caused by me in r25709.
          Hide
          anonymous Commit Message Bot added a comment -

          (extempore in r25979) Fix for regression in overriding with defaults.

          I should know better than to behave as if usable inferences can
          be drawn from a comment like "SYNTHETIC because of DEVIRTUALIZE".
          Maybe it was even true when it was written, but no more.
          Closes SI-5178, no review.

          Show
          anonymous Commit Message Bot added a comment - (extempore in r25979 ) Fix for regression in overriding with defaults. I should know better than to behave as if usable inferences can be drawn from a comment like "SYNTHETIC because of DEVIRTUALIZE". Maybe it was even true when it was written, but no more. Closes SI-5178 , no review.
          Hide
          rytz Lukas Rytz added a comment -

          i think we should rather put the correct flags instead of having a special case in override checking.

          Show
          rytz Lukas Rytz added a comment - i think we should rather put the correct flags instead of having a special case in override checking.
          Hide
          extempore Paul Phillips added a comment -

          That would be great! I was just putting it back the way it was before I regressed it, because this was preventing me from building scala-io. However I don't know what the correct flags are. (The default getters should inherit more flags from the relevant methods?)

          Show
          extempore Paul Phillips added a comment - That would be great! I was just putting it back the way it was before I regressed it, because this was preventing me from building scala-io. However I don't know what the correct flags are. (The default getters should inherit more flags from the relevant methods?)
          Hide
          rytz Lukas Rytz added a comment -

          no, but if you override a default, a second default getter is generated which overrides the one in the superclass. it should have the override flag. i'll have a look at some point.

          Show
          rytz Lukas Rytz added a comment - no, but if you override a default, a second default getter is generated which overrides the one in the superclass. it should have the override flag. i'll have a look at some point.
          Hide
          extempore Paul Phillips added a comment -

          I think it has the right flags in the straightforward case; it's when the self-type is involved that it doesn't. (See test/files/pos/t5178.scala.)

          Show
          extempore Paul Phillips added a comment - I think it has the right flags in the straightforward case; it's when the self-type is involved that it doesn't. (See test/files/pos/t5178.scala.)
          Hide
          rytz Lukas Rytz added a comment -

          we cannot assign the correct OVERRIDE flags to default getters. one and the same default getter might sometimes override another one, sometimes not, example below.

          this is a consequence of the fact that we allow overriding defaults without override modifiers.

          so the fix in 9f9932bd20 is left in place, a comment is added in 5d90d00108

          trait A1 { def f(x: Int): Int }
          trait A2 extends A1 { def f(x: Int = 1): Int }
           
          trait B { self: A1 =>
            def f(x: Int = 2): Int = x
          }
           
          object t {
            new A1 with B // here, B.f$default$1 should not have an 'override' flag
            new A2 with B // here, B.f$default$1 would need an 'override' flag
          }
          

          Show
          rytz Lukas Rytz added a comment - we cannot assign the correct OVERRIDE flags to default getters. one and the same default getter might sometimes override another one, sometimes not, example below. this is a consequence of the fact that we allow overriding defaults without override modifiers. so the fix in 9f9932bd20 is left in place, a comment is added in 5d90d00108 trait A1 { def f(x: Int): Int } trait A2 extends A1 { def f(x: Int = 1): Int }   trait B { self: A1 => def f(x: Int = 2): Int = x }   object t { new A1 with B // here, B.f$default$1 should not have an 'override' flag new A2 with B // here, B.f$default$1 would need an 'override' flag }

            People

            • Assignee:
              rytz Lukas Rytz
              Reporter:
              extempore Paul Phillips
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: