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

Unable to format file due to bug in scalafmt when configStyleArguments=false #1485

Closed
pxsdirac opened this issue Aug 26, 2019 · 0 comments · Fixed by #1729
Closed

Unable to format file due to bug in scalafmt when configStyleArguments=false #1485

pxsdirac opened this issue Aug 26, 2019 · 0 comments · Fixed by #1729
Labels

Comments

@pxsdirac
Copy link

pxsdirac commented Aug 26, 2019

  • Version: 2.0.0
  • Integration: IntelliJ, sbt
  • Configuration:
version = 2.0.0
style = IntelliJ
maxColumn = 120
docstrings = ScalaDoc

Steps

error log Exception in thread "main" org.scalafmt.Error$PreciseIncomplete: <input>:16: error: Unable to format file due to bug in scalafmt ) on save or run scalafmt in sbt.

origin code:

class A {
  def foo: B =
    a.b() { c =>
        val d = c.add(
          D[E](
            1, {
              case conditionNameShouldLongEnough =>
                foo1(objectNameShouldLongEnough, objectNameShouldLongEnough)
                0
              case conditionNameShouldLongEnough =>
                foo1(objectNameShouldLongEnough, objectNameShouldLongEnough)
                1
            }
          )
        )
      }
      .f("f")
}

Here is my demo to call internal api of scalafmt, it is proved that this bug is introduced by configuring optIn.configStyleArguments to false. style Intellij include this configuration, so using config file I paste above also has this issue.

import org.scalafmt.Scalafmt
import org.scalafmt.config.ScalafmtConfig.default
import org.scalafmt.config.{ContinuationIndent, Docstrings, ScalafmtConfig}

object Test extends App {
  val code =
    """
      |class A {
      |  def foo: B =
      |    a.b() { c =>
      |        val d = c.add(
      |          D[E](
      |            1, {
      |              case conditionNameShouldLongEnough =>
      |                foo1(objectNameShouldLongEnough, objectNameShouldLongEnough)
      |                0
      |              case conditionNameShouldLongEnough =>
      |                foo1(objectNameShouldLongEnough, objectNameShouldLongEnough)
      |                1
      |            }
      |          )
      |        )
      |      }
      |      .f("f")
      |}
    """.stripMargin
  println(code)
  val config = ScalafmtConfig.default.copy(
    version = "2.0.0",
    docstrings = Docstrings.ScalaDoc,
    maxColumn = 120,
    continuationIndent = ContinuationIndent(2, 2),
    optIn = default.optIn.copy(
      configStyleArguments = false
    ))

  val formattedCode = Scalafmt.format(code,style = config,range = Set.empty).get
  println(formattedCode)
}
@poslegm poslegm added the bug label Nov 9, 2019
kitbellew added a commit to kitbellew/scalafmt that referenced this issue Feb 21, 2020
Currently, the algorithm would clear the search priority queue when the
top candidate points to a new statement. Sometimes this leads to losing
a viable path and and a dreaded "Unable to format due to bug" error.

Rather than clearing the queue, let's inject states into the priority
queue with a generation value and decrement it on a new statement, thus
continuing to process subsequent states just like the old algorithm did
but with the previously discarded states available as backup.

Apply this modification to top-level invocations only, so that nested
calls will still terminate early; thus the backup candidates are really
processed at the very end of the existing logic.

Fixes scalameta#448. Fixes scalameta#1462. Fixes scalameta#1485. Fixes scalameta#1599. Fixes scalameta#1717.
kitbellew added a commit to kitbellew/scalafmt that referenced this issue Feb 21, 2020
Currently, the algorithm would clear the search priority queue when the
top candidate points to a new statement. Sometimes this leads to losing
a viable path and the dreaded "Unable to format due to bug" error.

Rather than clearing the queue, let's inject states into the priority
queue with a generation value and increment it on a new statement, thus
continuing to process subsequent states just like the old algorithm did
but with the previously discarded states available as backup.

Apply this modification to top-level invocations only, so that nested
calls will still terminate early; thus the backup candidates are really
processed at the very end of the existing logic.

Fixes scalameta#448. Fixes scalameta#1462. Fixes scalameta#1485. Fixes scalameta#1599. Fixes scalameta#1717.
kitbellew added a commit to kitbellew/scalafmt that referenced this issue Feb 21, 2020
Currently, the algorithm would clear the search priority queue when the
top candidate points to a new statement. Sometimes this leads to losing
a viable path and the dreaded "Unable to format due to bug" error.

Rather than clearing the queue, let's inject states into the priority
queue with a generation value and increment it on a new statement, thus
continuing to process subsequent states just like the old algorithm did
but with the previously discarded states available as backup.

Apply this modification to top-level invocations only, so that nested
calls will still terminate early; thus the backup candidates are really
processed at the very end of the existing logic.

Fixes scalameta#448. Fixes scalameta#1462. Fixes scalameta#1485. Fixes scalameta#1599. Fixes scalameta#1717.
kitbellew added a commit to kitbellew/scalafmt that referenced this issue Feb 21, 2020
Currently, the algorithm would clear the search priority queue when the
top candidate points to a new statement. Sometimes this leads to losing
a viable path and the dreaded "Unable to format due to bug" error.

Rather than clearing the queue, let's maintain several generations of
priority queues and create a new generation on a new statement, thus
continuing to process subsequent states just like the old algorithm did
but with the previously discarded states available as backup.

Apply this modification to top-level invocations only, so that nested
calls will still terminate early; thus the backup candidates are really
processed at the very end of the existing logic.

Fixes scalameta#448. Fixes scalameta#1462. Fixes scalameta#1485. Fixes scalameta#1599. Fixes scalameta#1717.
kitbellew added a commit that referenced this issue Feb 21, 2020
Currently, the algorithm would clear the search priority queue when the
top candidate points to a new statement. Sometimes this leads to losing
a viable path and the dreaded "Unable to format due to bug" error.

Rather than clearing the queue, let's maintain several generations of
priority queues and create a new generation on a new statement, thus
continuing to process subsequent states just like the old algorithm did
but with the previously discarded states available as backup.

Apply this modification to top-level invocations only, so that nested
calls will still terminate early; thus the backup candidates are really
processed at the very end of the existing logic.

Fixes #448. Fixes #1462. Fixes #1485. Fixes #1599. Fixes #1717.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants