Incremental compilation does not work if modified code is imported from a module that exported said code from elsewhere.

[phrmoy]

Compiler version

3.3.0

Minimized code

ModuleA.scala

object ModuleA {
  def func(x:Int) = x
}

ModuleB.scala

object ModuleB {
  export ModuleA.{*}
}

ModuleC.scala

object ModuleC {
  import ModuleB.{*}
  println(func(0))
}

The above works. Now if I change the ModuleA.scala to

ModuleA.scala

object ModuleA {
  def func(x:Int, y:Int) = x + y
}

and change ModuleC.scala to

ModuleC.scala

object ModuleC {
  import ModuleB.{*}
  println(func(0,0))
}

Both SBT and bloop fail to compile the code.

Bloop v1.5.6.
SBT v1.8.3

Output

From SBT

[error] 11 |  println(func(0, 0))
[error]    |               ^^^^
[error]    |               Found:    (Int, Int)
[error]    |               Required: Int
[error]    |----------------------------------------------------------------------------
[error]    | Explanation (enabled by `-explain`)
[error]    |- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

From Bloop

Found:    (Int, Int)
Required: Int

Expectation

Expected code to compile normally.

[phrmoy]

Howdy, how goes? For the lack of not understanding any better when and how open issues are handled, would it be ok for me to ask what would be an expected/average ETA for something like this to be fixed? Currently, I am still relying heavily on exports, and not being able to refactor (rename methods) without having to delete entire builds is really hurting development. Unfortunately, I cannot offer anything "more" at the moment, so I am merely asking. If the answer is "not planned" and/or "unkown" I understand, at least I will be able to plan accordingly. Thank you.

[bishabosha]

would it be ok for me to ask what would be an expected/average ETA for something like this to be fixed?

in general when prioritising bugs there is usually two considerations - did this break something that worked in the past, or is it blocking a large enough project.

Failing those it goes to asking how common the pattern is, so then if only 1 person is reporting it, then it would seem to not be a large issue (however i'm sure many people experience bugs but stay quiet for whatever reasons).

Personally, I assigned myself because I know the code, I can give a look in the morning, but otherwise if someone reads this and thinks they want to try a fix then don't hesitate to respond here and ill unassign myself

[phrmoy]

Thank you for your reply. I will leave some thoughts and a question.

in general when prioritising bugs there is usually two considerations - did this break something that worked in the past, or is it blocking a large enough project.

As far as the "defect" I am encountering, export works as expected "when it compiles." The problem is to get it to compile when you refactor. Thus it should not be breaking projects (if the code compiles).

Failing those it goes to asking how common the pattern is, so then if only 1 person is reporting it, then it would seem to not be a large issue (however i'm sure many people experience bugs but stay quiet for whatever reasons).

Despite the number of reports, for this particular case, one can reason to the conclusion that it impacts everyone who uses export in that if they refactor code, it makes the compiler throw false positives. That said, export works when it compiles. However, particularly for the people following the recommended Metals setup, it involves manually deleting the bloop folder to get the compiler to accept the refactored code. This is enough reason not to use export in the code, which one could argue next that it deems the export feature unusable. If this feature is not experimental, this should be under consideration. Sadly, I find export extremely useful (this sentiment, however, I cannot say if it's shared at large).

Now on to the question, would it be ok for me to reach out to the forum and raise awareness on this issue?

[bishabosha]

I can't reproduce the problem you are having from the snippets provided, you will need to be more specific about when each compilation occurs, and when each change occurs

steps I took:

• create a new sbt project from scala/scala3.g8
• set the scala version to 3.3.0 and sbt version to 1.8.3
• create ModuleA.scala, ModuleB.scala, ModuleC.scala as listed in src/main/scala
• compile (successful)
• copy the new ModuleA.scala and ModuleC.scala to src/main/scala
• compile (successful)

[phrmoy]

I have attached a short clip that at least shows the issue.

https://youtu.be/y54_IWrGQh8

[bishabosha]

I have attached a short clip that at least shows the issue.

https://youtu.be/y54_IWrGQh8

could you explain why there appears to be an implicit argument to export ModuleCUtils(x$1).{*}?

I still couldn't replicate this, (using same metals snapshot too) maybe you can create a GitHub project?

[phrmoy]

Thanks for looking into this.

I believe that implicit argument, in the video, seems to be coming from inside ModuleCUtils.

  opaque type ModuleCUtilsType = Object
  given ModuleCUtilsType = Object()
  def validateModuleCUtilsImports(using ModuleCUtilsType) = ()