-
-
Notifications
You must be signed in to change notification settings - Fork 410
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
Remove usage of JIT for tests #3857
Comments
|
As part of this, add a regression test for #2976: actor Main
new create(env: Env) =>
apply(env)
fun apply(env: Env) =>
test[I64](env, (0, true))
test[U64](env, (0, true))
fun test[A: Stringable #read](env: Env, expected: (A, Bool)) =>
busywork[A](env, expected._1)
fun busywork[A: Stringable #read](env: Env, expected: A) =>
"." + "." + "." + "." + "." + "." + "." + "." + "." + "." + "." + "." + "." |
|
There's a "it could look like this" draft PR open: |
|
At the moment, this is waiting for @kulibali's word on if it makes sense to integrate these into cmake build system (which we hope it does). |
|
@SeanTAllen I've committed some preliminary work in Note that the tests will need to be modified to link to libraries that are named after them (e.g. c-callback.lib). |
|
@kulibali is the plan for you to get everything on that branch to working and then i can take over again on trying to fit the rest of the more complicated tests in? |
|
I was thinking you could see if it's an approach you like and then cherry-pick from my branch what you want to include. |
|
@kulibali I'd rather work together on your branch together. Whatever either of us doesn't like, we can talk and adjust it. Does that work for you? If yes, I'd say, let me know when you are ready for me to do whatever my next thing is and let me know when its time and I'll start figuring out the state of things. |
|
@kulibali excellent idea to write the runner in Pony. very excellent idea. |
|
There's some work in my branch I'll keep working on the runner. |
|
Let me know when you want me to jump in @kulibali. |
|
@kulibali says the new runner is working and the next step is to use the new runner to convert all the tests. @kulibali and @SeanTAllen will tag team on converting the tests. |
|
We have 3 tests left to convert and probably some housekeeping around output format and what not to deal with. Those 3 tests that are left are rather tricky compared to all the others that were straightforward to do. |
Previously there were a number of tests in `tests/libponyc` that relied on the LLVM ORC JIT to test Pony compilation. Several of these never worked right on Windows or ARM. This PR (a collaboration between @SeanTAllen and @kulibali) removes all tests that depend on the JIT from `tests/libponyc` and moves them to individual directories in `tests/libponyc-run`. Updates the build system to build individual libraries from any C or C++ code found in subdirectories of `tests/libponyc-run` when running `make build` (`make.ps1 build` on Windows). These libraries end up in `build/{release,debug}`. Adds a program in `tests/libponyc-run/runner` that, during `make test`, does the following for each subdirectory in `tests/libponyc-run` that contains Pony code: - Runs `ponyc` on that directory, linking with the libraries built by `make build` as necessary. - Runs the resulting program, comparing the exit code with the value in `expected-exit-code.txt` (or `0` if that file does not exist). Fixes #3857 Fixes #2455 (the exception-catching test now works)
Currently we have a number of tests for functionality that use the JIT to run compiled code. This is handy for tests, however, the ORC JIT is still a "very moving" target. Additionally, it appears that it is buggy (or our usage of it is buggy) on Raspberry PI 4 32-bit which is one of our current Arm development platforms.
We've tentatively decided we will remove JIT usage from the codebase and switch to using *.pony source file programs that a freshly built ponyc can compile and then a test harness can run and compare the expected exit code to the actual exit code. That would cover what all the JIT based tests do.
Here's an example test from
codegen.cc:All the JIT tests can be identify by the call to
run_program.I would suggest starting with two tests to get working and see how difficult this will be.
The text was updated successfully, but these errors were encountered: