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

[compiler-v2] Decide whether specification language should do ability checks (breaking change) #12656

Open
wrwg opened this issue Mar 23, 2024 · 0 comments
Labels
bug Something isn't working compiler-v2 stale-exempt Prevents issues from being automatically marked and closed as stale

Comments

@wrwg
Copy link
Contributor

wrwg commented Mar 23, 2024

With the full support of ability checks via type constraints, the specification language would also be subject of ability checks. For instance, using exists<T>(addr) would require T to have the key ability.

However, this leads to breaking changes in existing code. Here is an example from the framework where T would required to be declared with the key ability:

  spec schema OnNewEpochAbortsIf<T> {
        ...
        aborts_if spec_fun_does_exist<T>(type_name) && !exists<T>(@aptos_framework);

This is probably ubiquitous also in user code.

For now, we have disabled ability checking in exp_builder (search for this bug number). We may want to revisit this and think about an upgrade path.

@wrwg wrwg added bug Something isn't working compiler-v2 labels Mar 23, 2024
@sausagee sausagee added the stale-exempt Prevents issues from being automatically marked and closed as stale label Mar 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working compiler-v2 stale-exempt Prevents issues from being automatically marked and closed as stale
Projects
Status: 📋 Backlog
Development

No branches or pull requests

2 participants