Skip to content

Type of Scanner.rest different in Scala 2.13 and Scala 3 #478

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

Closed
OndrejSpanel opened this issue Aug 24, 2022 · 2 comments
Closed

Type of Scanner.rest different in Scala 2.13 and Scala 3 #478

OndrejSpanel opened this issue Aug 24, 2022 · 2 comments

Comments

@OndrejSpanel
Copy link
Member

OndrejSpanel commented Aug 24, 2022

Following code compiles fine with Scala 2, but does not compile with Scala 3:

import scala.util.parsing.combinator.lexical.Lexical

class ScalaLikeLexer extends Lexical {
  sealed abstract class ScalaLikeToken extends Token {
    def toSource = chars
  }

  @annotation.tailrec
  private def parseAllTokensLoop(s: Scanner, prevTokens: Seq[ScalaLikeToken]): Seq[ScalaLikeToken] = {
    if (s.atEnd) prevTokens.reverse // reversed, so that we can prepend (this is fast on Seq)
    else parseAllTokensLoop(s.rest, s.first.asInstanceOf[ScalaLikeToken] +: prevTokens)
  }
}

The error with Scala 3 is:

Found: scala.util.parsing.input.Reader[ScalaLikeLexer.this.Token]
Required: ScalaLikeLexer.this.Scanner

See https://scastie.scala-lang.org/bxUTWXp5SNeaXpgvqm24Mw

The reason is type of Scanner.rest is not specified in the source. The method is implemented using new Scanner(rest2), therefore the type is Scanner in Scala 2, while it is Reader[Token] in Scala 3 (see https://docs.scala-lang.org/scala3/guides/migration/incompat-type-inference.html)

Could the type be provided explicitly as Scanner, so that it is the same in all Scala versions? Other overridden members of Scanner could perhaps receive the same treatment.

If this seems acceptable, I can prepare the PR if desired.

@SethTisue
Copy link
Member

Although I don't know the codebase well, the change certainly sounds plausible and desirable.

@Philippus
Copy link
Member

Fixed in #480.

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

No branches or pull requests

3 participants