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

Incorrect position in desugaring of a destructor val statement #13078

Open
kasiaMarek opened this issue Jan 9, 2025 · 1 comment
Open

Incorrect position in desugaring of a destructor val statement #13078

kasiaMarek opened this issue Jan 9, 2025 · 1 comment
Assignees

Comments

@kasiaMarek
Copy link

Reproduction steps

Scala version: 2.13.15

object O {
    def runtimeResources = {
        val (singleFiles, correctEntries) = (???, ???)
    }
}

desugars to (outprint with -Vprint -Vprint-pos)

[24:126]package [24:24]<empty> {
  [24:126]object O extends [33:126][33]scala.AnyRef {
    [33]def <init>(): [33]O.type = [33]{
      [33][33][33]O.super.<init>();
      [33]()
    };
    [39:124]def runtimeResources: [43]Unit = [62:124]{
      <72:118><synthetic> <artifact> private[this] val x$1: [76](Nothing, Nothing) = <76:118>[108:118]([108:118][108][108]scala.Tuple2.apply[[108]Nothing, [108]Nothing]([109:112]scala.Predef.???, [114:117]scala.Predef.???): [108]<type: [NoPosition][108:118][108][108]scala.Tuple2.apply[[108]Nothing, [108]Nothing]([109:112]scala.Predef.???, [114:117]scala.Predef.???): @[108]scala.unchecked>) match {
        <76:105>case <76:105>[76]<type: [76]scala.Tuple2>(<77:88>(singleFiles @ [77]_), <90:104>(correctEntries @ [90]_)) =>
        // I would expect the positions in line below to be (<77:88>singleFiles, <90:104>correctEntries) or for `x$1` definition to have zero-extend position
        <76:105><76:105><76:105>scala.Tuple2.apply[[76]Nothing, [76]Nothing](<76:105>singleFiles, <76:105>correctEntries)
      };
      [77:88]val singleFiles: [77]Nothing = [77]x$1._1;
      [90:104]val correctEntries: [90]Nothing = [90]x$1._2;
      [123]()
    }
  }
}

Problem

As noted in the comment I'd expect the positions in the apply with (singleFiles, correctEntries) to either point to the same positions as definitions of singleFiles and correctEntries or for the whole x$1 synthetic definition to have zero extend position.

Extra context

scalameta/metals#7086

@som-snytt
Copy link

Assigning myself because I intended to look at the related issue with multiple initialization.

Similar positions were important for for-comprehension desugaring and patvar tracking.

(Currently, I'm learning about dotty positions under inlining.)

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

2 participants