Skip to content

Scala.js: Add neg tests for bad uses of reflect.Selectable. #9611

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 2 commits into from
Aug 21, 2020

Conversation

sjrd
Copy link
Member

@sjrd sjrd commented Aug 21, 2020

We add some infrastructure to be able to perform neg tests that are specific to Scala.js. Such tests require the scalajs-library jar and the dotty-libraryJS jar on the classpath, and must be compiled with the -scalajs option.

We use this infrastructure to test existing compile errors reported for unsupported uses of reflect.Selectable in Scala.js.

We add some infrastructure to be able to perform neg tests that are
specific to Scala.js. Such tests require the scalajs-library jar
and the dotty-libraryJS jar on the classpath, and must be compiled
with the `-scalajs` option.

We use this infrastructure to test existing compile errors reported
for unsupported uses of `reflect.Selectable` in Scala.js.
@sjrd sjrd requested a review from smarter August 21, 2020 09:30
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! ❤️

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:

  1. Separate subject from body with a blank line
  2. When fixing an issue, start your commit message with Fix #<ISSUE-NBR>:
  3. Limit the subject line to 72 characters
  4. Capitalize the subject line
  5. Do not end the subject line with a period
  6. Use the imperative mood in the subject line ("Add" instead of "Added")
  7. Wrap the body at 80 characters
  8. Use the body to explain what and why vs. how

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

Have an awesome day! ☀️

@@ -705,7 +708,8 @@ object Build {
// running the compiler, we should always have the bootstrapped
// library on the compiler classpath since the non-bootstrapped one
// may not be binary-compatible.
"dotty-library" -> packageBin.in(`dotty-library-bootstrapped`, Compile).value
"dotty-library" -> packageBin.in(`dotty-library-bootstrapped`, Compile).value,
"dotty-library-js" -> packageBin.in(`dotty-library-bootstrappedJS`, Compile).value,
Copy link
Member

@smarter smarter Aug 21, 2020

Choose a reason for hiding this comment

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

If I run dotty-compiler/run, the bootstrappedJS library is now compiled whereas it wasn't before, this would slow down working in dotty in most cases where we're not working on scala.js support. Similarly, I should be able to run dotty-compiler/testCompilation tests/pos/foo without having to compile anything scala.js-related. So I suggest moving this stuff to another project, either an existing scala.js project like sjsJUnitTests or a new one as you prefer.

Copy link
Member Author

@sjrd sjrd Aug 21, 2020

Choose a reason for hiding this comment

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

It really doesn't slow anything down, because a) it gets compiled in parallel with dotty-library-bootstrapped and b) it takes roughly the same time. I see a difference of about 1 out of 9 seconds on my computers (my Windows at home and my Linux at work agree) between
a) dotty-library-bootstrapped/clean followed by dotty-compiler/packageAll, and
b) dotty-library-bootstrapped/clean and dotty-library-bootstrappedJS/clean followed by dotty-compiler/packageAll.

The alternative is to replicate a lot of infrastructure in a different project. There is currently no other project equipped to do that. This seems like a huge increase in complexity to avoid 1 second.

Copy link
Member

@smarter smarter Aug 21, 2020

Choose a reason for hiding this comment

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

There is currently no other project equipped to do that.

dotty-compiler-bootstrapped runs the regular tests + bootstrapped-only and staging-only tests, it works by overriding the packageAll task. You could either do the same in a different project or add the scalajs stuff to dotty-compiler-bootstrapped too, that way it doesn't impact non-bootstrapped tasks which would be acceptable.

Copy link
Member Author

Choose a reason for hiding this comment

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

Alright. Adding to the bootstrapped tests only was not an option for me, because that makes my dev cycle much much longer, since I would have to rebuild the bootstrapped compiler for every single change.

I added a separate project instead.

@smarter smarter assigned sjrd and unassigned smarter Aug 21, 2020
@sjrd sjrd requested a review from smarter August 21, 2020 13:43
@sjrd sjrd assigned smarter and unassigned sjrd Aug 21, 2020
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.

.github/workflows/ci.yaml needs to be updated to also run these tests if they're in a new project (presumably this should be added in the same job that currently runs the other sjs tests)

@@ -1140,6 +1140,27 @@ object Build {
}
)

lazy val sjsCompilerTests = project.in(file("tests/sjs-compiler-tests")).
Copy link
Member

Choose a reason for hiding this comment

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

I would put it at the top-level instead of in the tests/ directory since that directory should only contain code that we feed to the compiler to test it (hmm I've just now realized that we also have tests/sjs-junit which violates this, can't we merge these two things in one project anyway?). Also feel free to add a -boostrapped version of this project if needed.

dependsOn(`dotty-compiler` % "test->test").
settings(
commonNonBootstrappedSettings,
outputStrategy := Some(StdoutOutput),
Copy link
Member

Choose a reason for hiding this comment

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

Can we move this into thisBuildSettings or commonSettings to avoid having to repeat it in various projects?

This way, it is not necessary to compile
`dotty-library-bootstrappedJS` unless we want to run the
Scala.js-specific tests.

This reduces test coverage, since those tests won't be run with the
bootstrapped compiler anymore.
@sjrd sjrd force-pushed the sjs-neg-tests-infrastructure branch from d9e3f3f to eb54a18 Compare August 21, 2020 14:09
@sjrd
Copy link
Member Author

sjrd commented Aug 21, 2020

All done.

@sjrd sjrd merged commit 1fb07cb into scala:master Aug 21, 2020
@sjrd sjrd deleted the sjs-neg-tests-infrastructure branch August 21, 2020 15:40
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.

3 participants