-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Backend backport2 #124
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
Backend backport2 #124
Conversation
@odersky lets get this merged, it fixes several issues that trigger failures in checker. |
LGTM |
I'm OK with the rationale you have given for flags naming. |
ping @odersky |
def isJavaMainMethod(sym: Symbol)(implicit ctx: Context) = { | ||
val dn = defn | ||
(sym.name == nme.main) && (sym.info match { | ||
case t@MethodType(_, dn.ArrayType(el) :: Nil) => el =:= defn.StringType && t.resultType.typeSymbol == defn.UnitClass |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
t.resultType isRef dn.Unit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do I understand correctly that this is just shorter way to do same test?
Or are they actually different?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case it's just shorter, but in general isRef is more robust. I flagged it because it's important to be consistent everywhere. Otherwise the next person will choose one randomly depending on what idiom saw previously.
Otherwise, LGTM |
lazy val Array_apply = ctx.requiredMethod(ArrayClass, nme.apply) | ||
lazy val Array_update = ctx.requiredMethod(ArrayClass, nme.update) | ||
lazy val Array_length = ctx.requiredMethod(ArrayClass, nme.length) | ||
lazy val Array_clone = ctx.requiredMethod(ArrayClass, nme.clone_) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if it matters in Dotty, but in scalac these should be def
-s, not vals
. Why? Subsequent runs of the compiler might recompile Array
(this happens if you navigate to its sources in Scala IDE, for example), which would result in new symbols for its members.
That's why I split out RunDefinitions
in scalac, so we could have correctness and speed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For Dotty definitions are part of context and I would say that in case discarding is required, the better approach would be to discard context itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed we should do the same thing. (Keep them as lazyvals but break them
out into a new class) It's planned by has not been done yet. - Martin
On Tue, May 6, 2014 at 4:11 PM, Jason Zaugg [email protected]:
In src/dotty/tools/dotc/core/Definitions.scala:
@@ -168,6 +170,10 @@ class Definitions {
List(AnyClass.typeRef), EmptyScope)
lazy val SeqClass: ClassSymbol = ctx.requiredClass("scala.collection.Seq")
lazy val ArrayClass: ClassSymbol = ctx.requiredClass("scala.Array")
- lazy val Array_apply = ctx.requiredMethod(ArrayClass, nme.apply)
- lazy val Array_update = ctx.requiredMethod(ArrayClass, nme.update)
- lazy val Array_length = ctx.requiredMethod(ArrayClass, nme.length)
- lazy val Array_clone = ctx.requiredMethod(ArrayClass, nme.clone_)
Not sure if it matters in Dotty, but in scalac these should be def-s, not
vals. Why? Subsequent runs of the compiler might recompile Array (this
happens if you navigate to its sources in Scala IDE, for example), which
would result in new symbols for its members.That's why I split out RunDefinitions in scalac, so we could have
correctness and speed.—
Reply to this email directly or view it on GitHubhttps://github.com//pull/124/files#r12325734
.
Martin Odersky
EPFL
JOIN US. REGISTER TODAY! http://www.scaladays.org/
Scala http://www.scaladays.org/
Days http://www.scaladays.org/
June 16th-18th, http://www.scaladays.org/
Berlin http://www.scaladays.org/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Martin, why do you need a new class for this? Isn't Definitions itself a class that can be discarded with context holding it.
Collect entry points for backend. Previously this was done by cleanup.
TermRef's for primitive types are of primitive-type.
Conflicts: src/dotty/tools/dotc/backend/jvm/BCodeBodyBuilder.scala src/dotty/tools/dotc/core/Definitions.scala
The most important bit is fix for erasure, that was emitting such code: