Skip to content

ZIO Does Not Compile Against Latest Nightly Version of Dotty #7683

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
adamgfraser opened this issue Dec 4, 2019 · 15 comments
Closed

ZIO Does Not Compile Against Latest Nightly Version of Dotty #7683

adamgfraser opened this issue Dec 4, 2019 · 15 comments
Assignees

Comments

@adamgfraser
Copy link
Contributor

Following up discussion in zio/zio#2412 we are not able to compile ZIO against the latest nightly version of Dotty. We are testing all PRs against Dotty 0.20 as part of our CI process so it appears that the issue relates to a change since then. Specifically, I am getting the following error:

[error] not found: /drone/src/library/src/scala/internal/Quoted.scala
[error] not found: /drone/src/library/src/scala/internal/Quoted.scala
[error] not found: /drone/src/library/src/scala/internal/Quoted.scala
[error] not found: /drone/src/library/src/scala/quoted/QuoteContext.scala
[error] not found: /drone/src/library/src/scala/quoted/QuoteContext.scala
[error] not found: /drone/src/library/src/scala/quoted/QuoteContext.scala

To reproduce, you can change this line in ZIO to use the latest Dotty nightly and then attempt to compile after setting the version to Dotty or do the same thing with my local branch here.

Sorry I don't have a more detailed diagnosis. Copying @smarter and @neko-kai.

@nicolasstucki
Copy link
Contributor

@adamgfraser which sbt commands should I use to reproduce it?

@adamgfraser
Copy link
Contributor Author

@nicolasstucki See below.

./sbt
++ 0.21.0-bin-20191202-ccb7b13-NIGHTLY
project stacktracerJVM
compile

@nicolasstucki
Copy link
Contributor

If I publish the latest version of dotty locally it works. Maybe something is missing when publishing the artifacts. In which case 9e4ee9f looks like a likely suspect.

@smarter
Copy link
Member

smarter commented Dec 4, 2019

If I publish the latest version of dotty locally it works

If you publish it locally then the path to Quoted.scala will be a real file on your filesystem, so it makes sense that it would work and not emit a "not found" error.

@nicolasstucki
Copy link
Contributor

true

@nicolasstucki
Copy link
Contributor

nicolasstucki commented Dec 4, 2019

I bisected it and it started in 59ea176

@nicolasstucki
Copy link
Contributor

@smarter could you have a look? Revering 59ea176 fixes the issue

@smarter
Copy link
Member

smarter commented Dec 4, 2019

That looks completely unrelated, no idea.

@nicolasstucki
Copy link
Contributor

Double-checking it I saw that reverting it did not help

@nicolasstucki
Copy link
Contributor

It is actually 7185680

@nicolasstucki
Copy link
Contributor

@adamgfraser could you try to minimize it in a self-contained example? Debugging this on the full ZIO project will be too complex and will not allow us to add a good regression test.

@bishabosha
Copy link
Member

so if you unzip the jar file for the artifact ch.epfl.lamp:dotty-library_0.21-0.21.0-bin-20191202-ccb7b13-NIGHTLY, these strings can be found in the raw tasty files scala/quoted/QuoteContext.tasty and scala/internal/Quoted.tasty, but not in the contents if you do -print-tasty or -decompile on them

@smarter
Copy link
Member

smarter commented Dec 5, 2019

@adamgfraser
Copy link
Contributor Author

Yes. I was trying to minimize the example, at one point got a version with code commented out that compiled, and now I am able to compile the entire project successfully with no code commented out. So it seems like maybe there is some check for a missing file that is occurring too early, so we're not getting to the point where that file can be generated?

smarter added a commit to dotty-staging/dotty that referenced this issue Dec 5, 2019
In e07a728, I changed
Context#withSource to set a new CompilationUnit based on the source if
no compilation unit is currently set (always having a CompilationUnit
set is now needed since I moved the fresh name generator inside
CompilationUnit), however CompilationUnit#apply will error out if the
source file does not exist, which might happen for library code.

Fixed by adding a parameter to disable this check, but this is not very
pretty and we should really try to design a better way to distinguish
between user source files and source files we happen to know the name of
because it's stored in Tasty.
smarter added a commit to dotty-staging/dotty that referenced this issue Dec 5, 2019
In e07a728, I changed
Context#withSource to set a new CompilationUnit based on the source if
no compilation unit is currently set (always having a CompilationUnit
set is now needed since I moved the fresh name generator inside
CompilationUnit), however CompilationUnit#apply will error out if the
source file does not exist, which might happen for library code.

Fixed by adding a parameter to disable this check, but this is not very
pretty and we should really try to design a better way to distinguish
between user source files and source files we happen to know the name of
because it's stored in Tasty.
smarter added a commit that referenced this issue Dec 11, 2019
Fix #7683: Fix CompilationUnit handling in Context#withSource
@adamgfraser
Copy link
Contributor Author

Thank you!

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