Skip to content
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

Parser error resulting in "overloaded or recursive method needs return type" #3737

Closed
soronpo opened this issue Jan 3, 2018 · 8 comments
Closed

Comments

@soronpo
Copy link
Contributor

soronpo commented Jan 3, 2018

I also created a scastie link with the code.

object Main {
  def main(args: Array[String]) = println("")

  object Foo {
    def apply(t : Any)(block: => Unit) : Unit = {}
    def foo(t : Any)(block: => Unit) : Unit = {}
  }

  object Test {
    Foo(1){} //OK
    Foo.foo(1) {} //OK
    Foo foo(1) {} //overloaded or recursive method  needs return type
  }
}

Using -Xprint:parser, gives the following:

    parsed:
    package  {
      module object Main extends { 
         def main( args: Array[String]) = println("")
        module object Foo extends { 
           def apply( t: Any)( block: => Unit): Unit = 
            {
              
            }
           def foo( t: Any)( block: => Unit): Unit = 
            {
              
            }
        }
        module object Test extends { 
          Foo(1)(
            {
              
            }
          )
          Foo.foo(1)(
            {
              
            }
          )
          Foo foo 
            (1)(
              {
                
              }
            )
        }
      }
    }

@nicolasstucki
Copy link
Contributor

Minimization

object Main {
  object Foo {
    def foo(a : Int)(b: Int): Unit = ()
  }
  Foo foo(1)(2)
}
-- [E044] Syntax Error: Foo.scala:7:10 -----------------------------------------
7 |  Foo foo(1)(2)
  |          ^
  |          overloaded or recursive method <none> needs return type

@nicolasstucki
Copy link
Contributor

foo is parsed as an infix operator and then (1)(2) are parsed as 2 applied to 1.

InfixOp(
  Ident(Foo), 
  Ident(foo), 
  Apply(Parens(Literal(1)), List(Literal(2)))
)

@smarter
Copy link
Member

smarter commented Jan 3, 2018

The only issue I see here is the weird error message:

scala> 1(2) 
1 |1(2)
  |^
  |overloaded or recursive method <none> needs return type

The actual parsing is done exactly like scalac, changing the way we parse infix operators will require someone to come up with a specification of the changes and some good motivation.

@olafurpg
Copy link
Member

olafurpg commented Jan 3, 2018

The error message is a bit clearer in 2.12.4

scala> (1)(2)
<console>:12: error: Int(1) does not take parameters
       (1)(2)
          ^

@soronpo
Copy link
Contributor Author

soronpo commented Jan 3, 2018

The actual parsing is done exactly like scalac,

Yes, this example was also added to an existing ticket on the scalac issue tracker: scala/bug#8859

changing the way we parse infix operators will require someone to come up with a specification of the changes and some good motivation.

Can you point me where in the spec I can find this (the error) is the required behavior?

@soronpo
Copy link
Contributor Author

soronpo commented Jan 3, 2018

I should mention I have a use-case for this, but it's not a major-one to create a SIP and change the current intended behavior. I just wish for a confirmation that this is indeed the intended behavior, and I will close this issue. (and I can create a separate issue for the weird error message just for (1)(2)).

@smarter
Copy link
Member

smarter commented Jan 3, 2018

The syntax is described at http://www.scala-lang.org/files/archive/spec/2.12/13-syntax-summary.html for 2.12 and http://dotty.epfl.ch/docs/internals/syntax.html for dotty.

I think the current behavior matches the syntax description. Parsing Foo foo(1) {} is equivalent to parsing Foo foo (1) {}. The right-hand-side of an InfixExpr can be a SimpleExpr, and (1) {} is a valid SimpleExpr parsed as an application of (1) to {}.

@soronpo
Copy link
Contributor Author

soronpo commented Jan 3, 2018

OK. After further thinking about this, I believe this is the required behavior. I'll open a new issue for the error message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants