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

Expose charon as a rust library #178

Closed
Nadrieril opened this issue May 14, 2024 · 10 comments
Closed

Expose charon as a rust library #178

Nadrieril opened this issue May 14, 2024 · 10 comments
Assignees
Labels
A-internal Internal details of how charon is structured C-improvement

Comments

@Nadrieril
Copy link
Member

We'd like other rust users to be able to use Charon code. This may involve:

  • Make a library that exposes the ast types and helpers;
  • Detangle most micro-passes from rustc and make them available in the library;
  • Make the dependency on rustc optional behind a feature flag.
@Nadrieril Nadrieril added C-improvement A-internal Internal details of how charon is structured labels May 14, 2024
@Nadrieril Nadrieril self-assigned this May 14, 2024
@Nadrieril
Copy link
Member Author

Nadrieril commented Jul 4, 2024

#284 does most of that. charon-lib (which includes the ast definition and the control-flow reconstruction) should be pretty compatible with other rustc nightlies now. The only thing that remains would be to replace our usage of rustc internal crates for error reporting.

@zhassan-aws
Copy link
Contributor

Did you have plans/thoughts on how Charon can be restructured so that the library can be included without including the toolchain-dependent crates in the dependencies (e.g. hax-frontend-exporter)?

Currently, including the Charon library as a dependency brings in the dependencies used in the binaries as well.

Unfortunately, cargo doesn't allow specifying binary-specific dependencies easily:

rust-lang/cargo#1982

The workarounds from what I understand are:

  1. Use a workspace, and use different packages for the library and the binaries
  2. Make hax-frontend-exporter an optional dependency under a feature that is only used for the binaries. One would need to pass --features X when building the binaries though.

@Nadrieril
Copy link
Member Author

Nadrieril commented Aug 6, 2024

Oh yeah, I was thinking we'd add a feature flag. Either is fine probably.

@Nadrieril
Copy link
Member Author

Nadrieril commented Aug 7, 2024

Alright, this should now work on many nightly compilers:

[dependencies]
charon = { git = "https://github.com/AeneasVerif/charon", default-features = false }

@Nadrieril
Copy link
Member Author

The most interesting modules are ast which contains all the ast definitions, and transform which contains the code for the various transformations we do after translation, including control-flow reconstruction.

I believe the current state is good enough to close this issue, lmk if not.

@zhassan-aws
Copy link
Contributor

Awesome, thanks @Nadrieril!

@zhassan-aws
Copy link
Contributor

Looks like a hax dependency got added to the library recently:

use hax_frontend_exporter as hax;

This was introduced in 316a376

Is there a way around it? I'm happy to contribute if you can provide some guidance.

FYI, I opened a PR in Kani that is the first step in adding an LLBC/Aeneas backend: model-checking/kani#3514. Thanks for making this possible!

@Nadrieril
Copy link
Member Author

Nadrieril commented Sep 16, 2024

Oops, my mistake. I don't know an easy way to ask rust to enforce binary-only dependencies. Give me just a minute to fix that.

@Nadrieril
Copy link
Member Author

Fixed in #360

@zhassan-aws
Copy link
Contributor

Thanks for the quick fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-internal Internal details of how charon is structured C-improvement
Projects
None yet
Development

No branches or pull requests

2 participants