Skip to content

Remove compilation units for classes that have already been loaded #3700

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

Merged

Conversation

nicolasstucki
Copy link
Contributor

If not, we would create two compilation units that try to load the same class.

Copy link
Member

@smarter smarter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A similar thing will happen if I do dotc Foo.scala Foo.scala. I think it'd be better to avoid passing duplicated names to TASTYRun#compile in the first place.

@nicolasstucki
Copy link
Contributor Author

Now in both cases the file/class names are deduplicated.

@@ -26,7 +26,7 @@ class Driver extends DotClass {
if (fileNames.nonEmpty)
try {
val run = compiler.newRun
run.compile(fileNames)
run.compile(fileNames.distinct)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure this is a great thing to do:

  • It doesn't deduplicate between Foo.scala and /a/b/c/Foo.scala
  • List#distinct is O(n^2), that's not great when compiling 10000 files.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then maybe I should keep only the fix on the TASTY ones. With those the compiler crashes. With dotc Foo.scala Foo.scala the compiler will emit the error saying that the class is duplicated, which is already fine.

The implementation of List@distinct I see is in SeqLike and it does look O(n).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah indeed, List#distinct uses a hashset so it's probably more like n*log(n) which is acceptable. But why does the compiler crash when compiling twice the same TASTY file? Could we get it to output an error instead?

@nicolasstucki nicolasstucki force-pushed the fix-decompiler-on-duplicates branch from 183985c to 72ca652 Compare December 24, 2017 16:42
@nicolasstucki nicolasstucki force-pushed the fix-decompiler-on-duplicates branch from 72ca652 to 367bf61 Compare December 24, 2017 17:56
@nicolasstucki nicolasstucki changed the title Deduplicate class names before starting compiling from TASTY Remove compilation units for classes that have already been loaded Dec 24, 2017
@nicolasstucki nicolasstucki dismissed smarter’s stale review December 24, 2017 17:57

Reworked code from scratch

unit.pickled += (cls -> cls.unpickler.unpickler.bytes)
cls.unpickler = null
Some(unit)
if (cls.unpickler == null) None // Has already been loaded by some other compilation unit
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe make it an error?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes and done

@nicolasstucki nicolasstucki merged commit 1080529 into scala:master Dec 28, 2017
@allanrenucci allanrenucci deleted the fix-decompiler-on-duplicates branch December 28, 2017 22:11
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

Successfully merging this pull request may close these issues.

2 participants