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

Write a version of assert which allows a msg to be passed to the simulator #1434

Closed
iAmMichaelConnor opened this issue Aug 7, 2023 · 5 comments
Assignees
Labels
A-ux/devex Area: relates to external ux / devex. (Users typically are devs) (See also A-internal-devex) T-testing Type: Testing. More tests need to be added.

Comments

@iAmMichaelConnor
Copy link
Contributor

At the moment, assert(condition) doesn't enable an error message to be given.

assert(condition, error_msg) would be lovely.

Now, I'm not sure if this is an issue that should be opened in the noir-lang repo, or if this is something we'll need to implement ourselves, to enable to the error message to be passed directly to the simulator via an oracle call.

E.g. we could create a wrapper function contract_assert(condition, error_msg), which under the hood does an assert(condition) and then does an oracle call with the message?

Tagging @sirasistant for inspirational ideas :)

@iAmMichaelConnor iAmMichaelConnor added T-testing Type: Testing. More tests need to be added. A-ux/devex Area: relates to external ux / devex. (Users typically are devs) (See also A-internal-devex) labels Aug 7, 2023
@github-project-automation github-project-automation bot moved this to Todo in A3 Aug 7, 2023
@sirasistant
Copy link
Contributor

I think that given the fact that we now have stepwise execution of ACIR we could just create a wrapper assert fn that if the condition is false calls an oracle with the message and then asserts the condition, and it would work fine for aztec (although It could be a bit inefficient), receiving the oracle call and then failing. But this could be much easier if the acir expressions could just have a message attached in case they fail.
The only advantage of this method over #1224 is for the case where we don't have access to the source code of the contract. It might be valuable even for regular noir. Will discuss with the noir team!

@iAmMichaelConnor
Copy link
Contributor Author

although It could be a bit inefficient

Why would this be inefficient?

The only advantage of this method over #1224 is for the case where we don't have access to the source code of the contract

Yeah, it was that discussion that made me open this issue. Distributing source code isn't guaranteed (although validation of source code against bytecode should be encouraged, of course). Distributing the bytecode is guaranteed.

@sirasistant
Copy link
Contributor

sirasistant commented Aug 8, 2023

Why would this be inefficient?

For every assert with message you'll end up with two opcodes, the expression itself and a brillig opcode to send the message just before. But It would be only executed in the case of failure which should be ok

@sirasistant
Copy link
Contributor

This issue is being worked on the noir side in this issue noir-lang/noir#1939

@sirasistant
Copy link
Contributor

Done in #1997
both assert and assert_eq support an optional literal string parameter now

@github-project-automation github-project-automation bot moved this from Todo to Done in A3 Sep 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ux/devex Area: relates to external ux / devex. (Users typically are devs) (See also A-internal-devex) T-testing Type: Testing. More tests need to be added.
Projects
Archived in project
Development

No branches or pull requests

2 participants