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
      

        Activity

        Hide
        Paul Phillips added a comment -

        Caused by me in r25709.

        Show
        Paul Phillips added a comment - Caused by me in r25709.
        Hide
        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
        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
        Lukas Rytz added a comment -

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

        Show
        Lukas Rytz added a comment - i think we should rather put the correct flags instead of having a special case in override checking.
        Hide
        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
        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
        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
        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
        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
        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
        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
        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:
            Lukas Rytz
            Reporter:
            Paul Phillips
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development