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

Fix compilation of panic!() when the arg is another macro. #1407

Merged
merged 2 commits into from
Jul 26, 2022

Conversation

celinval
Copy link
Contributor

Description of changes:

In rust, a macro cannot expand another macro that was given as an argument. However, some of the std macros are expanded inside the compiler, which gives them a way around that.

Because we implement those macros are regular macros, we cannot expand other macros and we also cannot limit the first argument to be a literal.

I decided for now to just relax what we accept as the first argument.

Resolved issues:

Resolves #1386

Call-outs:

This solution us to accept whatever the std panic!() macro accepts, but it may accept invalid things as well, such as:

  panic!("invalid" / "division");

That was already accepted as the other arguments of these macros, so I don't think this is big step back. This also won't impact soundness since whatever issue that could rise from creating the expression is inside a panic statement; thus verification has failed already.

Testing:

  • How is this change tested? New test + old tests.

  • Is this a refactor change? No

Checklist

  • Each commit message has a non-empty body, explaining why the change was made
  • Methods or procedures are documented
  • Regression or unit tests are included, or existing tests cover the modified code
  • My PR is restricted to a single feature or bugfix

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

In rust, a macro cannot expand another macro that was given as an
argument. However, some of the std macros are expanded inside the
compiler, which gives them a way around that.

Because we implement those macros are regular macros, we cannot expand
other macros and we also cannot limit the first argument to be a
literal.

I decided for now to just relax what we accept as the first argument.
This allow us to accept whatever the std panic!() macro accepts, but it
may accept invalid things as well, such as:

```
  panic!("invalid" / "division");
```

That was already accepted as the second or third arguments, so I don't
think this is big step back. This also won't impact soundness since
whatever issue that could rise from creating the expression is already
inside a panic statement; thus verification has failed already.
@celinval celinval requested a review from a team as a code owner July 25, 2022 20:38
@tedinski tedinski merged commit 9f20e84 into model-checking:main Jul 26, 2022
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 this pull request may close these issues.

Compilation fails with a panic macro
3 participants