Scala.js: Implement the PrepJSInterop phase, minus exports handling. #9725

sjrd · 2020-09-04T12:36:52Z

The PrepJSInterop phase is responsible for:

Performing all kinds of Scala.js-specific compile-time checks, and emitting the appropriate compile errors.
Perform some transformations that are necessary for JavaScript interop, notably generating exports forwarders.

This commit ports all the functionality of PrepJSInterop from Scala 2, except the following:

Handling of scala.Enumerations: it is unclear whether we still want to support that in the core, or if it should be handled by an optional compiler plugin in the future.
Exports: they will be done later.
Warnings about duplicate fields in js.Dynamic.literal: mostly because they are non-essential.

The test cases are ported from the Scala.js compiler tests.

dottybot

Hello, and thank you for opening this PR! 🎉

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

Commit Messages

We want to keep history, but for that to actually be useful we have
some rules on how to format our commit messages (relevant xkcd).

Please stick to these guidelines for commit messages:

Separate subject from body with a blank line

When fixing an issue, start your commit message with Fix #<ISSUE-NBR>:

Limit the subject line to 72 characters

Capitalize the subject line

Do not end the subject line with a period

Use the imperative mood in the subject line ("Add" instead of "Added")

Wrap the body at 80 characters

Use the body to explain what and why vs. how

adapted from https://chris.beams.io/posts/git-commit

Have an awesome day! ☀️

compiler/src/dotty/tools/dotc/ast/Desugar.scala

compiler/src/dotty/tools/dotc/core/Annotations.scala

compiler/src/dotty/tools/dotc/core/SymDenotations.scala

compiler/src/dotty/tools/dotc/transform/sjs/JSInteropUtils.scala

nicolasstucki · 2020-09-10T14:42:22Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+
+    /** Nicer syntax for `allEnclosingOwners isnt kind`. */
+    private object noEnclosingOwner {
+      @inline def is(kind: OwnerKind): Boolean =


Suggested change

@inline def is(kind: OwnerKind): Boolean =

inline def is(kind: OwnerKind): Boolean =

It turns out noEnclosingOwner was dead code, so I removed it entirely. I changed the @inline defs inside OwnerKind itself to inline, except | for which I could not do it (I added a comment).

Those that one get inlined by the Scala2 backend? Is that valid bytecode?

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

sjrd

Thanks for the review! I think I have addressed all your comments.

sjrd · 2020-09-11T07:58:55Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+
+    /** Nicer syntax for `allEnclosingOwners isnt kind`. */
+    private object noEnclosingOwner {
+      @inline def is(kind: OwnerKind): Boolean =


It turns out noEnclosingOwner was dead code, so I removed it entirely. I changed the @inline defs inside OwnerKind itself to inline, except | for which I could not do it (I added a comment).

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

gzm0 · 2020-09-13T11:35:59Z

Diff between PrepJSInterop.scala in this PR and in Scala.js v1.2.0: https://gist.github.com/gzm0/8f515e48bb0918c56efab31cccbaaf17

gzm0

Mostly higher level comments. Hopefully we can settle the overall approach question before I continue the review. IMO it quite changes what I'm looking for.

compiler/src/dotty/tools/dotc/core/SymDenotations.scala

gzm0 · 2020-09-13T09:17:01Z

compiler/src/dotty/tools/dotc/config/SJSPlatform.scala

+    !sym.isSubClass(jsDefinitions.JSAnyClass)
+
+  object perRunInfo {
+    private val jsNativeLoadSpecs = new MutableSymbolMap[JSNativeLoadSpec]


Is this common practice in dotty? IMO we have resorted to mutable, per-run maps in Scala.js for 2.x because we couldn't recover all of the required info from the trees (or we couldn't store them on the symbol). However, I don't think in general this is a good pattern: It introduces mutable state in a pipeline that doesn't look like it.

No, it's not common practice. I went for the smallest logical diff wrt. our Scala 2 implementation.

I'll try to move this computation to the back-end and see if we can avoid the issue.

gzm0 · 2020-09-13T09:23:30Z

compiler/src/dotty/tools/backend/sjs/JSCodeGen.scala

+        genApplyJSClassMethod(module, sym, arguments = Nil)
+    } else {
+      genApplyMethod(module, sym, arguments = Nil)
+    }


It seems odd that the distinction of receiver types needs to be made here.

It's also done in scala-js/scala-js:
https://github.com/scala-js/scala-js/blob/730931a3a11b351ea850a5c6107cfbd332c52a9b/compiler/src/main/scala/org/scalajs/nscplugin/GenJSCode.scala#L6171-L6188

That is necessary because the owner SomeObject referred to in an @JSName(SomeObject.aSymbolVal) can be a Scala object, a native JS object or a non-native JS object.

gzm0 · 2020-09-13T09:32:59Z

compiler/src/dotty/tools/backend/sjs/JSDefinitions.scala

@@ -50,6 +52,11 @@ final class JSDefinitions()(using Context) {
  @threadUnsafe lazy val PseudoUnionType: TypeRef = requiredClassRef("scala.scalajs.js.|")
  def PseudoUnionClass(using Context) = PseudoUnionType.symbol.asClass

+  @threadUnsafe lazy val PseudoUnionModuleRef = requiredModuleRef("scala.scalajs.js.|")


Do we still need to special case this? I thought dotty supports union types.

Dotty supports union types, but it can also interoperate with Scala 2 libraries. And in particular with the pseudo | type in scalajs-library, which could itself be referenced by other methods in the std lib or in third-party libs. In Scala 3.0, we'll still need to recognize Scala.js' | type and correctly handle it. In 3.1, when we get rid of the compatibility with Scala 2 binaries, we'll be able to entirely drop scala.scalajs.js.| from the library, and have all usages of | be the true union type of dotty.

Also note that we cannot "reinterpret" scala.scalajs.js.| as a dotty union type during Scala2Unpickler because they do not have the same erasure: scala.scalajs.js.|[A, B] erases to any with a ClassRef("scala.scalajs.js.|"), whereas a true A | B erases to the JVM lub of A and B, with a corresponding ClassRef.

Also note that we cannot "reinterpret" scala.scalajs.js.| as a dotty union type during Scala2Unpickler because they do not have the same erasure

The same is true for Scala 2 intersection types versus Dotty &, I have a wip branch which erases those differently, so we could extend that mechanism to handle unions too if needed.

You mean we could reinterpret scala.scalajs.js.| as a special brand of union type that somehow erases differently? That would be awesome!

Yes that should be doable.

gzm0 · 2020-09-13T09:36:30Z

compiler/src/dotty/tools/dotc/config/SJSPlatform.scala

@@ -16,4 +25,27 @@ class SJSPlatform()(using Context) extends JavaPlatform {
    defn.isFunctionClass(cls)
      || jsDefinitions.isJSFunctionClass(cls)
      || jsDefinitions.isJSThisFunctionClass(cls)
+
+  override def shouldReceiveJavaSerializationMethods(sym: ClassSymbol)(using Context): Boolean =
+    !sym.isSubClass(jsDefinitions.JSAnyClass)


Why is this not simply false? This seems to add private methods with magic names relevant for Java serialization. Scala.js doesn't support this anyways, no?

Because the Scala classes and objects might be transitively used by macros and other compile-time code. I would rather have them be somewhat equivalent to the ones we would get in a JVM project. The JVM back-end will slap an extends java.io.Serializable to them, so we should be consistent and also emit the proper serialization methods, I believe.

gzm0 · 2020-09-13T09:41:24Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSExports.scala

+object PrepJSExports {
+  import tpd._
+
+  def registerClassOrModuleExports(sym: Symbol)(using Context): Unit = {


Similarly to how to handle load specs: I think for dotty, where JS support is considered part of the same compiler, we should consider adding the relevant infrastructure that language specific compilers can store specific information on Symbols. (because this is what is essentially happening here).

IMO this will feel much more natural than having these mutable maps.

I'll see if we can do that, yes. But whether or not we can, we'll still have a registerClassOrModuleExports here to actually store that data, whatever the mechanism. So I believe that this method shell can stay regardless. Only its body would change depending on whether we store things inside Symbols or in side-channels Maps.

gzm0 · 2020-09-13T09:43:43Z

tests/neg-scalajs/abstract-local-js-class.check

+-- Error: tests/neg-scalajs/abstract-local-js-class.scala:6:19 ---------------------------------------------------------
+6 |    abstract class AbstractLocalJSClass extends js.Object // error
+  |    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  |    Implementation restriction: local JS classes cannot be abstract


Why do we have this restriction? (especially post scala-js/scala-js#4117, it feels pretty clear that abstract is merely a compile time concept).

Because of the way we implement the local captures of the constructor. We need ExplicitJSClasses to create a fake New(TheLocalJSClass, fakeParams), which lambdaLift (or its equivalent) enhances with the captures for local vals. The back-end captures the transformed fake New to recover those.

If the class is abstract, we cannot create that New without triggering internal inconsistencies. We also cannot blindly remove the Abstract flag, because the class could contain abstract methods, which still creates inconsistencies.

gzm0 · 2020-09-13T09:47:29Z

tests/neg-scalajs/internal-annotations.check

+-- Error: tests/neg-scalajs/internal-annotations.scala:16:0 ------------------------------------------------------------
+16 |@ExposedJSMember class D // error
+   |^^^^^^^^^^^^^^^^
+   |@scala.scalajs.js.annotation.internal.ExposedJSMember is for compiler internal use only. Do not use it yourself.


Similar comment about storing info on Symbols: IMO we should store these things in Symbols and store it in class files (if necessary) in the same way other dotty specific info is stored.

Or in other words: Scala.js compiler internal annotations should not be necessary anymore.

At the very least, we need them for 2-way compatibility with Scala 2-compiled code. So in Scala 3.0 we don't have any other option. We could revisit and simplify in Scala 3.1 when we get rid of the binary compatibility with Scala 2.

gzm0 · 2020-09-13T09:57:20Z

tests/neg-scalajs/jsconstructortag1.check

@@ -0,0 +1,27 @@
+-- Error: tests/neg-scalajs/jsconstructortag1.scala:9:39 ---------------------------------------------------------------


These test names (jsconstructortag1 / jsconstructortag2) are not very good. If there is a semantic reason why there are two checks (and it seems there is), they should be part of the name.

Same for cosntructorof.

gzm0 · 2020-09-13T11:42:03Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+    /** Whether to check that we have proper literals in some crucial places.
+     *
+     *  This is always true in dotc. We keep the definition so that the code
+     *  code can be as similar as possible to the scalac phase.


This reasoning (keep things close together) seems to be inconsistently applied across this file. For example: fixPublicBeforeTyper has been fully removed (instead of replaced by an identity function).

I think we should stick to one approach here. Personally, I think it is probably worth diverging, but doing it properly (i.e. remove things we don't need, etc.).

OTOH, we should invest to share tests suites as much as we can to avoid (and/or identify) feature/behavior divergence.

Normally, annotations applied to a class have no business being replicated on a synthetic companion object. One exception was the `@alpha` method, which is supposed to apply as well. Instead of trying to identify those annotations without the symbols during `Desugar`, we change `erasedName` to go look on the companion class of synthetic module classes.

sjrd

Only some answers to the comments for now. I'll take action on them tomorrow.

sjrd · 2020-09-13T15:52:14Z

compiler/src/dotty/tools/backend/sjs/JSCodeGen.scala

+        genApplyJSClassMethod(module, sym, arguments = Nil)
+    } else {
+      genApplyMethod(module, sym, arguments = Nil)
+    }


It's also done in scala-js/scala-js:
https://github.com/scala-js/scala-js/blob/730931a3a11b351ea850a5c6107cfbd332c52a9b/compiler/src/main/scala/org/scalajs/nscplugin/GenJSCode.scala#L6171-L6188

That is necessary because the owner SomeObject referred to in an @JSName(SomeObject.aSymbolVal) can be a Scala object, a native JS object or a non-native JS object.

sjrd · 2020-09-13T15:56:00Z

compiler/src/dotty/tools/backend/sjs/JSDefinitions.scala

@@ -50,6 +52,11 @@ final class JSDefinitions()(using Context) {
  @threadUnsafe lazy val PseudoUnionType: TypeRef = requiredClassRef("scala.scalajs.js.|")
  def PseudoUnionClass(using Context) = PseudoUnionType.symbol.asClass

+  @threadUnsafe lazy val PseudoUnionModuleRef = requiredModuleRef("scala.scalajs.js.|")


Dotty supports union types, but it can also interoperate with Scala 2 libraries. And in particular with the pseudo | type in scalajs-library, which could itself be referenced by other methods in the std lib or in third-party libs. In Scala 3.0, we'll still need to recognize Scala.js' | type and correctly handle it. In 3.1, when we get rid of the compatibility with Scala 2 binaries, we'll be able to entirely drop scala.scalajs.js.| from the library, and have all usages of | be the true union type of dotty.

Also note that we cannot "reinterpret" scala.scalajs.js.| as a dotty union type during Scala2Unpickler because they do not have the same erasure: scala.scalajs.js.|[A, B] erases to any with a ClassRef("scala.scalajs.js.|"), whereas a true A | B erases to the JVM lub of A and B, with a corresponding ClassRef.

sjrd · 2020-09-13T15:58:39Z

compiler/src/dotty/tools/dotc/config/SJSPlatform.scala

@@ -16,4 +25,27 @@ class SJSPlatform()(using Context) extends JavaPlatform {
    defn.isFunctionClass(cls)
      || jsDefinitions.isJSFunctionClass(cls)
      || jsDefinitions.isJSThisFunctionClass(cls)
+
+  override def shouldReceiveJavaSerializationMethods(sym: ClassSymbol)(using Context): Boolean =
+    !sym.isSubClass(jsDefinitions.JSAnyClass)


Because the Scala classes and objects might be transitively used by macros and other compile-time code. I would rather have them be somewhat equivalent to the ones we would get in a JVM project. The JVM back-end will slap an extends java.io.Serializable to them, so we should be consistent and also emit the proper serialization methods, I believe.

sjrd · 2020-09-13T16:03:03Z

compiler/src/dotty/tools/dotc/config/SJSPlatform.scala

+    !sym.isSubClass(jsDefinitions.JSAnyClass)
+
+  object perRunInfo {
+    private val jsNativeLoadSpecs = new MutableSymbolMap[JSNativeLoadSpec]


No, it's not common practice. I went for the smallest logical diff wrt. our Scala 2 implementation.

I'll try to move this computation to the back-end and see if we can avoid the issue.

sjrd · 2020-09-13T16:06:13Z

compiler/src/dotty/tools/dotc/transform/sjs/JSInteropUtils.scala

+
+import dotty.tools.backend.sjs.JSDefinitions.jsdefn
+
+object JSInteropUtils {


I'll rename this to JSSymUtils, which is consistent with transform.SymUtils that already exists in dotty (and which is also a bunch of extension methods on Symbol).

For JSName, do you mean move it inside another object called JSData?

sjrd · 2020-09-13T16:08:09Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSExports.scala

+object PrepJSExports {
+  import tpd._
+
+  def registerClassOrModuleExports(sym: Symbol)(using Context): Unit = {


I'll see if we can do that, yes. But whether or not we can, we'll still have a registerClassOrModuleExports here to actually store that data, whatever the mechanism. So I believe that this method shell can stay regardless. Only its body would change depending on whether we store things inside Symbols or in side-channels Maps.

sjrd · 2020-09-13T16:10:54Z

tests/neg-scalajs/abstract-local-js-class.check

+-- Error: tests/neg-scalajs/abstract-local-js-class.scala:6:19 ---------------------------------------------------------
+6 |    abstract class AbstractLocalJSClass extends js.Object // error
+  |    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+  |    Implementation restriction: local JS classes cannot be abstract


Because of the way we implement the local captures of the constructor. We need ExplicitJSClasses to create a fake New(TheLocalJSClass, fakeParams), which lambdaLift (or its equivalent) enhances with the captures for local vals. The back-end captures the transformed fake New to recover those.

If the class is abstract, we cannot create that New without triggering internal inconsistencies. We also cannot blindly remove the Abstract flag, because the class could contain abstract methods, which still creates inconsistencies.

sjrd · 2020-09-13T16:11:57Z

tests/neg-scalajs/internal-annotations.check

+-- Error: tests/neg-scalajs/internal-annotations.scala:16:0 ------------------------------------------------------------
+16 |@ExposedJSMember class D // error
+   |^^^^^^^^^^^^^^^^
+   |@scala.scalajs.js.annotation.internal.ExposedJSMember is for compiler internal use only. Do not use it yourself.


At the very least, we need them for 2-way compatibility with Scala 2-compiled code. So in Scala 3.0 we don't have any other option. We could revisit and simplify in Scala 3.1 when we get rid of the binary compatibility with Scala 2.

sjrd

Updated. I believe I have addressed all the comments so far. The only question is where to put JSName, but IMO it's find where it is.

I've kept things in different commits for an easier re-review, but all the commits except the first one should be squashed before merging.

sjrd · 2020-09-14T09:46:07Z

compiler/src/dotty/tools/backend/sjs/JSDefinitions.scala

@@ -50,6 +52,11 @@ final class JSDefinitions()(using Context) {
  @threadUnsafe lazy val PseudoUnionType: TypeRef = requiredClassRef("scala.scalajs.js.|")
  def PseudoUnionClass(using Context) = PseudoUnionType.symbol.asClass

+  @threadUnsafe lazy val PseudoUnionModuleRef = requiredModuleRef("scala.scalajs.js.|")


You mean we could reinterpret scala.scalajs.js.| as a special brand of union type that somehow erases differently? That would be awesome!

gzm0

Only minor comments.

gzm0 · 2020-09-14T13:46:51Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+    }
+
+    private def transformScalaValOrDefDef(tree: ValOrDefDef)(using Context): Tree = {
+      // There is nothing special to do for a Scala val or def


Consider removing this helper and simply moving the comment to the call-site.

gzm0 · 2020-09-14T13:49:26Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+                tree)
+          }
+          super.transform(tree)
+        */


Commented out on purpose?

I've removed it.

gzm0 · 2020-09-14T13:51:53Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+        sym.isAnonymousClass && AllJSFunctionClasses.exists(sym.isSubClass(_))
+      if (isJSLambda)
+        transformJSLambdaClassDef(classDef)
+      else*/


I take it lambdas reach this phase as a special node? If yes, I think all of this code should be removed in this PR.

gzm0 · 2020-09-14T13:52:42Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+          case parentSym if parentSym == defn.DynamicClass =>
+            /* We have to allow scala.Dynamic to be able to define js.Dynamic
+             * and similar constructs.
+             * This causes the unsoundness filed as #1385.


filed as scala-js/scala-js#1385?

gzm0 · 2020-09-14T13:54:01Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+              errorPos)
+          }
+
+          // Check for overrides with different JS names - issue #1983


issue scala-js/scala-js#1983?

gzm0 · 2020-09-14T16:43:02Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+        def checkGlobalRefPath(pathName: String): Unit =
+          checkGlobalRefName(firstElementOfPath(pathName))
+
+        checkAndGetJSNativeLoadingSpecAnnotOf(pos, sym) match {


This is a bit confusing IMO. Because both the helper and this method check things (and there is only this call site of the helper). Not sure how to improve it easily though.

That was bothering me as well, but I didn't find a better name, and I still don't find one now, so I'll leave it as is for now.

gzm0 · 2020-09-14T16:43:55Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+          val dotIndex = pathName.indexOf('.')
+          if (dotIndex < 0) pathName
+          else pathName.substring(0, dotIndex)
+        }


Consider inlining this to checkGlobalRefPath (the only call site).

gzm0 · 2020-09-14T16:47:10Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+          }
+
+        case nme.equals_ if sym.info.matches(defn.Any_equals.info) =>
+          report.warning(


Consider making this fatal since we have the chance? (Ideally we'd just make these final IIUC, not sure if this works, given that js.Any is a trait).

gzm0 · 2020-09-14T16:50:43Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+          report.error("@JSBracketCall is not allowed in non-native JS classes", tree)
+        } else {
+          // JS bracket calls must have at least one non-repeated parameter
+          sym.info.stripPoly match {


This check doesn't flatten parameter lists. Is this on purpose? (IIUC, Scala.js 2.x does flatten lists).

This is on purpose. In Scala.js 2.x we also don't flatten the lists:
https://github.com/scala-js/scala-js/blob/49dd4263301fe9d099906ccd02c0b4f27e479591/compiler/src/main/scala/org/scalajs/nscplugin/PrepJSInterop.scala#L936-L943

gzm0 · 2020-09-14T16:56:52Z

compiler/src/dotty/tools/dotc/transform/sjs/PrepJSInterop.scala

+  }
+
+  def isJSAny(sym: Symbol)(using Context): Boolean =
+    sym.isSubClass(jsdefn.JSAnyClass)


Is this deliberately different from sym.isJSType?

Yes. I have added a comment.

The `PrepJSInterop` phase is responsible for: * Performing all kinds of Scala.js-specific compile-time checks, and emitting the appropriate compile errors. * Perform some transformations that are necessary for JavaScript interop, notably generating exports forwarders. This commit ports all the functionality of `PrepJSInterop` from Scala 2, except the following: * Handling of `scala.Enumeration`s: it is unclear whether we still want to support that in the core, or if it should be handled by an optional compiler plugin in the future. * Exports: they will be done later. * Warnings about duplicate fields in `js.Dynamic.literal`: mostly because they are non-essential. The test cases are ported from the Scala.js compiler tests.

aappddeevv · 2020-09-14T23:58:41Z

I'm glad to see this.

I'm not sure how the build pipeline works, but does this show up in the nightly build and becomes usable if we use the nightly dotty build or do we need to wait until the related scala.js sbt plugins are updated?

sjrd · 2020-09-15T05:26:26Z

It should be available in the nightly builds of dotty. In any case it's orthogonal to the version of sbt-scalajs.

sjrd requested review from gzm0 and nicolasstucki September 4, 2020 12:36

sjrd assigned gzm0 and nicolasstucki Sep 4, 2020

dottybot reviewed Sep 4, 2020

View reviewed changes

smarter reviewed Sep 4, 2020

View reviewed changes

compiler/src/dotty/tools/dotc/ast/Desugar.scala Outdated Show resolved Hide resolved

sjrd force-pushed the sjs-prep-js-interop branch 2 times, most recently from 7f75e30 to 23d59e4 Compare September 7, 2020 12:10

nicolasstucki reviewed Sep 8, 2020

View reviewed changes

sjrd force-pushed the sjs-prep-js-interop branch 2 times, most recently from 9048512 to 8179687 Compare September 9, 2020 14:51

This was referenced Sep 10, 2020

dotty scalajs: @JSImport has no effect #9762

Closed

Scala.js: Various JS interop fixes #9763

Closed

sjrd force-pushed the sjs-prep-js-interop branch from 8179687 to 1550b84 Compare September 10, 2020 14:35

sjrd mentioned this pull request Sep 10, 2020

Scala.js: Various JS interop fixes #9767

Merged

nicolasstucki reviewed Sep 10, 2020

View reviewed changes

sjrd force-pushed the sjs-prep-js-interop branch from 1550b84 to 442e205 Compare September 11, 2020 08:49

sjrd commented Sep 11, 2020

View reviewed changes

nicolasstucki approved these changes Sep 11, 2020

View reviewed changes

gzm0 reviewed Sep 13, 2020

View reviewed changes

sjrd force-pushed the sjs-prep-js-interop branch from 442e205 to 6f6f710 Compare September 13, 2020 15:47

sjrd commented Sep 13, 2020

View reviewed changes

sjrd commented Sep 14, 2020

View reviewed changes

sjrd requested a review from gzm0 September 14, 2020 10:29

gzm0 approved these changes Sep 14, 2020

View reviewed changes

sjrd force-pushed the sjs-prep-js-interop branch from 05308c5 to 9bcba44 Compare September 14, 2020 20:05

sjrd merged commit cbb05c8 into scala:master Sep 14, 2020

sjrd deleted the sjs-prep-js-interop branch September 14, 2020 21:04

aappddeevv mentioned this pull request Sep 18, 2020

dotty scalajs toplevel object import compilation failure #9755

Closed

Kordyjan added this to the 3.0.0 milestone Aug 2, 2023

	@inline def is(kind: OwnerKind): Boolean =
	inline def is(kind: OwnerKind): Boolean =

		@@ -0,0 +1,27 @@
		-- Error: tests/neg-scalajs/jsconstructortag1.scala:9:39 ---------------------------------------------------------------


		import dotty.tools.backend.sjs.JSDefinitions.jsdefn

		object JSInteropUtils {

Scala.js: Implement the PrepJSInterop phase, minus exports handling. #9725

Scala.js: Implement the PrepJSInterop phase, minus exports handling. #9725

Conversation

sjrd commented Sep 4, 2020

dottybot left a comment

Choose a reason for hiding this comment

Commit Messages

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sjrd left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gzm0 commented Sep 13, 2020

gzm0 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sjrd left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sjrd left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gzm0 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aappddeevv commented Sep 14, 2020

sjrd commented Sep 15, 2020

sjrd left a comment •

edited

Loading