Skip to content
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

Add auto out test support for opaque types #1735

Open
FluxusMagna opened this issue Oct 12, 2022 · 3 comments
Open

Add auto out test support for opaque types #1735

FluxusMagna opened this issue Oct 12, 2022 · 3 comments

Comments

@FluxusMagna
Copy link

FluxusMagna commented Oct 12, 2022

This would be helpful to ensure programs with opaque outputs don't regress.

One way to avoid the issue of changes in data format between compiler versions could be to have an output script, similar to the script input currently available, which would take the output and convert it to a type that can be stored in a stable format (a tuple of scalars and arrays).

It would also be good to extend support for scripted inputs to this, so that any entry point can tested against prior versions and for different backends.

@athas
Copy link
Member

athas commented Oct 12, 2022

script output would be equivalent to wrapping the entry point a function that does the rewriting. That is already possible.

This would be a useful feature, but I don't think ensuring (or checking for) stability across compiler versions is important. Two reasons:

  1. Realistically, the format doesn't change that often. Off the top of my head, I'm not sure it has ever changed. The only change I can imagine is that we may improve deduplication for sum types.
  2. The format is stable across different compiler backends, which is more often useful.

@FluxusMagna
Copy link
Author

FluxusMagna commented Oct 12, 2022

The issue with wrapping in the program is code duplication, which increases compile times. adding a test would essentially double the compile time for a function (assuming the wrapper is small).

If you think the built in serialization is stable enough, I'm all for it.

edit: Now that I think about it, didn't you add some kind of deduplication step, or at least somehow reduce the amount of generated code a while back?

@athas
Copy link
Member

athas commented Oct 12, 2022

You can use #[noinline] inside the wrapper. (And in the future, we'll inline less aggressively.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants