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 an attribute to mark definitions as opaque #206

Closed
sonmarcho opened this issue May 29, 2024 · 8 comments · Fixed by #227
Closed

Add an attribute to mark definitions as opaque #206

sonmarcho opened this issue May 29, 2024 · 8 comments · Fixed by #227
Assignees

Comments

@sonmarcho
Copy link
Member

It is currently possible to pass an option to Charon to mark some modules as opaque, so that Charon will not look inside those definitions (it treats them similarly to external definitions). This option is a bit coarse grained: it would be good to be able to individually mark the functions with a charon::opaque attribute. In order not to confuse the Aeneas users, I suggest introducing a aeneas::opaque attribute which does the same, and generally speaking introducing both a charon::... and an aeneas::... version of every new attribute.

@Nadrieril
Copy link
Member

Note: rustc will complain about such an attribute because it will try to find a macro with that name. Adding

#![feature(register_tool)]
#![register_tool(charon)]

at the top of each file that uses the attributes should solve the problem I hope. We can think of a cleaner solution afterwards. (See here for details about this feature).

@sonmarcho
Copy link
Member Author

Ok, thanks for looking into this. My understanding is that there are clean ways of doing this, but I'm indeed not aware of the details. It might be worth looking at other verification projects which use attributes (e.g., Verus or Creusot).

@Nadrieril
Copy link
Member

Nadrieril commented May 30, 2024

Creusot defines a proc-macro for their #[ensures]/#[invariant] etc attributes. That's one of the options available (and you started doing something like that with the attributes crate).

@sonmarcho
Copy link
Member Author

What do you recommend doing?
I initially thought that was the only way of doing, but I would prefer a way which doesn't require adding a dependency to Charon directly in the Rust code.

@Nadrieril
Copy link
Member

Nadrieril commented May 30, 2024

register_tool is the simplest right now. I've heard discussions on the rustc side about what the best design for this feature would be, so I'd suggest using it for now and they'll likely figure out something more practical, e.g. a line to add in your Cargo.toml.

@zhassan-aws
Copy link
Contributor

In case it helps, in Kani, we pass feature(register_tool) as part of the Rust flags:

https://github.com/model-checking/kani/blob/4a889397bba73fb76f0a21aad66171daad0b2b31/kani-driver/src/call_single_file.rs#L175-L178

@Nadrieril
Copy link
Member

Nadrieril commented Jun 6, 2024

#227 allows the attribute on definitions; it would be nice to also allow the attribute on modules.

@Nadrieril Nadrieril reopened this Jun 6, 2024
@Nadrieril
Copy link
Member

These attributes are supported on modules since one of the recent PRs that overhauled opaque handling.

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 a pull request may close this issue.

4 participants