Skip to content

Fix #9772: Normalize value definitions #9836

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
merged 4 commits into from
Oct 15, 2020
Merged

Conversation

tudorv91
Copy link
Contributor

@tudorv91 tudorv91 commented Sep 20, 2020

Copy link
Member

@dottybot dottybot left a comment

Choose a reason for hiding this comment

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

Hello, and thank you for opening this PR! 🎉

All contributors have signed the CLA, thank you! ❤️

Have an awesome day! ☀️

@bishabosha bishabosha self-assigned this Sep 21, 2020
Copy link
Member

@bishabosha bishabosha left a comment

Choose a reason for hiding this comment

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

Thank you for opening this pull request, however I think this needs more consideration, for example, it is illegal to define object extension_foo, which suggests that val definitions should also be covered by this check, or else it is a bug for objects to cause this error.

What do you think @smarter?

@bishabosha
Copy link
Member

This pull request should probably also check the name of the generated setter, e.g. as shown in #9926 extension_= will be blocked by the compiler, but this PR would allow var extension

@bishabosha
Copy link
Member

conflicts also need to be resolved. @tudorv91 are you able to look at this?

@tudorv91
Copy link
Contributor Author

tudorv91 commented Oct 1, 2020

@bishabosha sure I'll have a look

@tudorv91 tudorv91 force-pushed the fix-#9772 branch 5 times, most recently from 139ab3e to 305e5b7 Compare October 3, 2020 06:21
@tudorv91
Copy link
Contributor Author

tudorv91 commented Oct 3, 2020

This pull request should probably also check the name of the generated setter, e.g. as shown in #9926 extension_= will be blocked by the compiler, but this PR would allow var extension

@bishabosha Implemented the extension name restriction for variables definitions. I have considered a more general restriction (that would also apply to immutable values), but decided against in fear of this limitation's effects on expressivity and legacy code. What do you think?

Copy link
Member

@bishabosha bishabosha left a comment

Choose a reason for hiding this comment

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

looks pretty good, thank you, I have a few suggestions

@tudorv91 tudorv91 force-pushed the fix-#9772 branch 2 times, most recently from 21c8e26 to 76e4ef2 Compare October 11, 2020 18:12
@tudorv91 tudorv91 requested a review from bishabosha October 11, 2020 18:21
@bishabosha
Copy link
Member

test performance please

@dottybot
Copy link
Member

performance test scheduled: 1 job(s) in queue, 0 running.

&& (!mods.is(Private) || ctx.owner.is(Trait) || ctx.owner.isPackageObject)
if (setterNeeded) {

val valName = normalizeName(vdef, tpt).asTermName
Copy link
Member

@bishabosha bishabosha Oct 14, 2020

Choose a reason for hiding this comment

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

perhaps isSetterNeeded could be a default parameter for normalizeName to avoid calling it twice, and then swap the conditions in the Valdef branch (case vdef: ValDef if isSetterNeeded && name.isExtension), but if the performance isn't impacted that much this is minor

Copy link
Contributor Author

@tudorv91 tudorv91 Oct 14, 2020

Choose a reason for hiding this comment

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

Yes, I considered that as well, but decided against it in order not to particularize the arg list of normalizeName with a param that is relevant to one branch. The second call would happen only if the valDef's name is extension, so I would expect it to be highly exceptional

Copy link
Member

@bishabosha bishabosha left a comment

Choose a reason for hiding this comment

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

Thank you for taking this on, I think this looks good.

.jvmopts Outdated
@@ -1,4 +1,6 @@
-Xss1m
-Xms512m
-Xmx1200m
-Xmx4096m
Copy link
Member

Choose a reason for hiding this comment

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

also are the changes to this file necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, strange that it appears as a diff. This is what's on master, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Rebased against the upstream and it's fine now

@dottybot
Copy link
Member

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/9836/ to see the changes.

Benchmarks is based on merging with master (68a7c03)

@bishabosha
Copy link
Member

test performance please

@dottybot
Copy link
Member

performance test scheduled: 1 job(s) in queue, 0 running.

@dottybot
Copy link
Member

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/9836/ to see the changes.

Benchmarks is based on merging with master (68a7c03)

@bishabosha
Copy link
Member

bishabosha commented Oct 14, 2020

pretty strange error in the CI for test_bootstrapped:

bootstrapped/test;sjsSandbox/run;sjsSandbox/test;sjsJUnitTests/test;sjsCompilerTests/test ;configureIDE"
Exception in thread "sbt-parser-init-thread" java.lang.ExceptionInInitializerError
	at sbt.internal.parser.SbtParserInit$$anon$2.run(SbtParser.scala:171)
Caused by: scala.reflect.internal.FatalError: Error accessing /root/.sbt/0.13/java9-rt-ext-ubuntu_11_0_7/rt.jar
	at scala.tools.nsc.classpath.AggregateClassPath.$anonfun$list$3(AggregateClassPath.scala:99)
	at scala.collection.Iterator.foreach(Iterator.scala:941)
	at scala.collection.Iterator.foreach$(Iterator.scala:941)
	at scala.collection.AbstractIterator.foreach(Iterator.scala:1429)
	at scala.collection.IterableLike.foreach(IterableLike.scala:74)
	at scala.collection.IterableLike.foreach$(IterableLike.scala:73)
	at scala.collection.AbstractIterable.foreach(Iterable.scala:56)
	at scala.tools.nsc.classpath.AggregateClassPath.list(AggregateClassPath.scala:87)
	at scala.tools.nsc.util.ClassPath.list(ClassPath.scala:36)
	at scala.tools.nsc.util.ClassPath.list$(ClassPath.scala:36)
	at scala.tools.nsc.classpath.AggregateClassPath.list(AggregateClassPath.scala:30)
	at scala.tools.nsc.symtab.SymbolLoaders$PackageLoader.doComplete(SymbolLoaders.scala:284)
	at scala.tools.nsc.symtab.SymbolLoaders$SymbolLoader.complete(SymbolLoaders.scala:230)
	at scala.reflect.internal.Symbols$Symbol.info(Symbols.scala:1542)
	at scala.reflect.internal.Mirrors$RootsBase.init(Mirrors.scala:257)
	at scala.tools.nsc.Global.rootMirror$lzycompute(Global.scala:74)
	at scala.tools.nsc.Global.rootMirror(Global.scala:72)
	at scala.tools.nsc.Global.rootMirror(Global.scala:44)
	at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass$lzycompute(Definitions.scala:295)
	at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass(Definitions.scala:295)
	at scala.reflect.internal.Definitions$DefinitionsClass.init(Definitions.scala:1480)
	at scala.tools.nsc.Global$Run.<init>(Global.scala:1199)
	at sbt.internal.parser.SbtParser$.<init>(SbtParser.scala:121)
	at sbt.internal.parser.SbtParser$.<clinit>(SbtParser.scala)
	... 1 more
Caused by: java.io.IOException: Error accessing /root/.sbt/0.13/java9-rt-ext-ubuntu_11_0_7/rt.jar
	at scala.reflect.io.FileZipArchive.scala$reflect$io$FileZipArchive$$openZipFile(ZipArchive.scala:141)
	at scala.reflect.io.FileZipArchive.root$lzycompute(ZipArchive.scala:179)
	at scala.reflect.io.FileZipArchive.root(ZipArchive.scala:176)
	at scala.reflect.io.FileZipArchive.allDirs$lzycompute(ZipArchive.scala:212)
	at scala.reflect.io.FileZipArchive.allDirs(ZipArchive.scala:212)
	at scala.tools.nsc.classpath.ZipArchiveFileLookup.findDirEntry(ZipArchiveFileLookup.scala:76)
	at scala.tools.nsc.classpath.ZipArchiveFileLookup.list(ZipArchiveFileLookup.scala:63)
	at scala.tools.nsc.classpath.ZipArchiveFileLookup.list$(ZipArchiveFileLookup.scala:62)
	at scala.tools.nsc.classpath.ZipAndJarClassPathFactory$ZipArchiveClassPath.list(ZipAndJarFileLookupFactory.scala:56)
	at scala.tools.nsc.classpath.AggregateClassPath.$anonfun$list$3(AggregateClassPath.scala:91)
	... 24 more
Caused by: java.util.zip.ZipException: zip END header not found
	at java.base/java.util.zip.ZipFile$Source.zerror(ZipFile.java:1535)
	at java.base/java.util.zip.ZipFile$Source.findEND(ZipFile.java:1436)
	at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1443)
	at java.base/java.util.zip.ZipFile$Source.<init>(ZipFile.java:1274)
	at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
	at java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:727)
	at java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
	at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:247)
	at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:177)
	at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:191)
	at scala.reflect.io.FileZipArchive.scala$reflect$io$FileZipArchive$$openZipFile(ZipArchive.scala:138)
	... 33 more
[info] welcome to sbt 1.3.12 (Ubuntu Java 11.0.7)
Error:  java.lang.NoClassDefFoundError: Could not initialize class sbt.internal.parser.SbtParser$
Error:  Use 'last' for the full log.
Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore? 
Error: Process completed with exit code 1.

@smarter
Copy link
Member

smarter commented Oct 14, 2020

pretty strange error in the CI for test_bootstrapped:

This is likely fixed by sbt/zinc#915

@bishabosha
Copy link
Member

bishabosha commented Oct 14, 2020

would make sense seeing as this suddenly happened after .jvmops stack size and heap were reset to master branch

tudorv91 and others added 4 commits October 14, 2020 22:28
* Restrict names for mutable values which lead to setter generation during desugaring
* Make `extension` variable names illegal
* Fix scala#9772: Disallow `extension_` for immutable values
Co-authored-by: Jamie Thompson <bishbashboshjt@gmail.com>
Co-authored-by: Jamie Thompson <bishbashboshjt@gmail.com>
@tudorv91
Copy link
Contributor Author

tudorv91 commented Oct 14, 2020

@bishabosha I've rebased again and now it seems to be fine, especially if it was unrelated to my changes. Looking at the benchmarks, they don't seem to deviate significantly. What do you think?

@bishabosha bishabosha merged commit 63771ac into scala:master Oct 15, 2020
@bishabosha
Copy link
Member

thanks a lot :)

@Kordyjan Kordyjan added this to the 3.0.0 milestone Aug 2, 2023
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.

5 participants