{"push_id":1337261600,"size":7,"distinct_size":7,"ref":"refs/heads/master","head":"b0482dfe9019149a88d690d661251c5f248be6ab","before":"5629883bd52784ed9b6cbb15e74b208085834bc5","commits":[{"sha":"eb6cd45946b2e38d86692a68e391a43ccb8324fa","author":{"name":"Sébastien Doeraene","email":"5cda95cd79970b005585520e16c2f516f7ff3b66@gmail.com"},"message":"Bump the IR version number for the upcoming changes.","distinct":true,"url":"https://api.github.com/repos/scala-js/scala-js/commits/eb6cd45946b2e38d86692a68e391a43ccb8324fa"},{"sha":"91474870d11fff0de73f10a361c92fc7345e3a8a","author":{"name":"Sébastien Doeraene","email":"5cda95cd79970b005585520e16c2f516f7ff3b66@gmail.com"},"message":"Fix #2552: Store generalized \"loading spec\" for native things in IR.\n\nPreviously, only native JS classes stored in the IR the means to\nload their constructor. This was stored as the `jsName` field, which\nwas the fully qualified name of the class constructor, starting from\nthe global object.\n\nThis information was notably used by the `LoadJSConstructor` IR node,\nallowing that node to be valid both for native JS classes and\nScala.js-defined JS classes.\n\nNative JS objects did not have a similar information, which caused\n`LoadJSModule` to be valid only for Scala.js-defined JS objects.\nTherefore, for native JS objects, the \"desugaring\" of `LoadJSModule`\nthat would logically happen at link-time was done by the compiler.\nThis meant that changing the `@JSName` of a native JS object was\nnot a binary compatible change, as recorded in issue #2552.\n\nThis commit fixes this issue, and in the process generalizes the\nstored information as \"loading spec\". Loading specs apply both to\nnative JS classes and objects. They are a declarative specification\nof how a class constructor or an object should be loaded by\n`LoadJSConstructor` and `LoadJSModule`, respectively.\n\nInstead of storing the unstructured fully qualified name, a loading\nspec is an ADT with, currently, only one possible case, which is\n`Global(path: List[String])`. In the future, other loading spec\nkinds will be added, such as imports from ES6 modules (see #2175).\n\nSince now both classes and objects have a loading spec, we cannot\nuse `jsName.isDefined` to identify native JS classes anymore (which\nis necessary for IR checks and when emitting the run-time\n`isInstance` reflective functions for raw JS types). To recover this\ndistinction in the IR, we split `ClassKind.RawJSType` into three:\n`NativeJSClass`, `NativeJSModuleClass` and `AbstractJSType` (the\nlatter being used for JS traits). With this information, we can\ncheck that `LoadJSConstructor` is valid for `NativeJSClass` and that\n`LoadJSModule` is valid for `NativeJSModuleClass`.\n\nWe add a deserialization hack to turn `RawJSType` from the 0.6.8\nformat into `NativeJSClass` if there was a `jsName` (which we also\nturn into a loading spec). There is a hack on top of the hack,\nthough. Since `jsName` is only visible in the tree, we cannot\napply this hack to the `kind` stored in the infos. Therefore, the\n`kind` in the infos may be inconsistent with that in the tree.\nThis is only a slight issue for the `Analyzer`, which therefore has\nanother hack to tolerate an `AbstractJSType` where it expects a\n`NativeJSClass`.\n\nNote that native JS *objects* compiled with the 0.6.8 format will\nbe deserialized as `AbstractJSType`, which means that\n`LoadJSModule` cannot be used on them. This means that even the new\ncompiler must eagerly desugar `LoadJSModule` when loading native JS\nmodules compiled by an older compiler, as it used to always do.\nSince there is no way to otherwise tell whether an object was\ncompiled with a recent compiler or not, we add a marker annotation\n`@HasJSNativeLoadSpec` to native JS objects compiled with the 0.6.13\nformat or later. For those, we can issue a `LoadJSModule` node.\n\nIn summary, this commit provides:\n\n- A fix for #2552 for objects compiled with 0.6.13 or later.\n- A generalized loading spec which can be extended to ES6 imports\n  in the future.","distinct":true,"url":"https://api.github.com/repos/scala-js/scala-js/commits/91474870d11fff0de73f10a361c92fc7345e3a8a"},{"sha":"e6068253c8d80f4778f22e14ef3fd523b7e96309","author":{"name":"Sébastien Doeraene","email":"5cda95cd79970b005585520e16c2f516f7ff3b66@gmail.com"},"message":"Always default to `persistLauncher in Test := false`.\n\nEven when `persistLauncher` is set to `true` for the Compile\nconfiguration, it should stay `false` in the `Test` configuration\nby default.","distinct":true,"url":"https://api.github.com/repos/scala-js/scala-js/commits/e6068253c8d80f4778f22e14ef3fd523b7e96309"},{"sha":"ef482bc6f80c211ab730942638b9196c6c8f8fd4","author":{"name":"Sébastien Doeraene","email":"5cda95cd79970b005585520e16c2f516f7ff3b66@gmail.com"},"message":"Honor `exportsNamespace` in the test interface and the test suite.\n\nThe testing interface and the test suite had hard-coded that the\nexports namespace of Scala.js was always the global scope. This\ncommit fixes this by looking up the actual exports namespace in\nthe environment info.","distinct":true,"url":"https://api.github.com/repos/scala-js/scala-js/commits/ef482bc6f80c211ab730942638b9196c6c8f8fd4"},{"sha":"27a05001ee5bdcd9845dd86a05409f939487bce4","author":{"name":"Sébastien Doeraene","email":"5cda95cd79970b005585520e16c2f516f7ff3b66@gmail.com"},"message":"Refactor Linker.apply() with a Config object.\n\nInstead of having a long list of parameters with default values,\nwe now use a `Config` object for all optional parameters. This\ncan be evolved in a binary compatible way in the future.","distinct":true,"url":"https://api.github.com/repos/scala-js/scala-js/commits/27a05001ee5bdcd9845dd86a05409f939487bce4"},{"sha":"2ac8233d77e7675538a79d224a44d632a108e487","author":{"name":"Sébastien Doeraene","email":"5cda95cd79970b005585520e16c2f516f7ff3b66@gmail.com"},"message":"Add `@JSImport` and the generation of CommonJS modules.\n\nThis is the first and biggest step towards #2175. It contains all\nthe semantic changes to the language and the IR. The only thing\nthat is left is to actually emit ES2015 modules rather than\nCommonJS modules in the emitter.\n\nThis commit contains two major changes, which are inherently linked:\n\n* An `@JSImport` annotation which can be used on top-level native JS\n  classes and objects to signify that they should be imported from\n  a JavaScript module.\n* A backend configuration `ModuleKind`, which instructs the emitter\n  to generate a CommonJS module, rather than a script meant to be\n  executed at the top-level of a JS engine.\n\nA codebase containing a reachable `@JSImport` cannot be successfully\nemitted to a top-level script, as there is no universal way of\nimporting things.\n\nWe could imagine emitting Node.js modules without `@JSImport` support\nat first, but it would be a bit nonsensical to have modules that\ncannot import from other modules.\n\nWhen emitting a module, top-level `@JSExport`s become the module\nexports, obviously.\n\nSemantically, `@JSImport` and `@JSExport` are ES2015 module imports\nand exports. They are therefore static, which means that a) things\ncannot be conditionally imported or exported and b) their \"key\"\nmust be a compile-time string constant.\n\nThe `ModuleKind` can be specified in sbt with the new key\n`scalaJSModuleKind`, which is scoped per project and per\nconfiguration, but not per stage. Indeed, they specify the interface\nwith the outside JavaScript world, and that should not change in\nfastOpt versus fullOpt. Obviously, setting `scalaJSModuleKind` to\n`CommonJSModule` requires Node.js to be used for `run` and `test`\ntasks.\n\nThe historical fact that the `scalaJSLauncher` is stage-independent\nunfortunately makes `packageJSLauncher` incompatible with a\n`scalaJSModuleKind` different from `NoModule`. This is because, with\nmodules, the contents of the launcher must reference the module ID,\nwhich is different in fastOpt and fullOpt.\n\nIn the future, we will extend `ModuleKind` with a new kind for\nactual ECMAScript 2015 modules.","distinct":true,"url":"https://api.github.com/repos/scala-js/scala-js/commits/2ac8233d77e7675538a79d224a44d632a108e487"},{"sha":"b0482dfe9019149a88d690d661251c5f248be6ab","author":{"name":"Tobias Schlatter","email":"36c5bbefeb290c7a456f392d21ced31cf0271e32@meisch.ch"},"message":"Merge pull request #2572 from sjrd/modules\n\nAdd `@JSImport` and the generation of CommonJS modules.","distinct":true,"url":"https://api.github.com/repos/scala-js/scala-js/commits/b0482dfe9019149a88d690d661251c5f248be6ab"}]}
{"actor":{"display_login":"gzm0"}}