-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
lang: Error on undocumented unsafe account types #1452
lang: Error on undocumented unsafe account types #1452
Conversation
@armaniferrante what is your preferred approach for fixing up
to features in Anchor.toml to skip it all, or add something like I'm not familiar enough with the program to write sensible comments. I could try and figure it out but it'll hold this up for a while. |
Let's just add safety_checks = false. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add an integration test to assert that the build does actually fail if CHECK isn't provided to prevent regressions.
Writing the test now. |
will this go into |
what is the proper way to use the program.invoke method ? |
okay I see, use the |
I seem to be getting a false positive on all of our PDAs.
triggers a warning |
@archseer this is expected. Here's the rationale #1452 (comment). More discussion on this is welcomed. |
This results in a bunch of comments for accounts which are not read (just used for their public key) or for accounts in which we only read/change the lamport balance (should be supported by all accounts). Ideally, this would be a type that enforces just these access methods rather than comments. In my ideal world, UncheckedAccount would only expose lamports and public key and none of the other data in it, and then not need a comment. |
Adds a documentation requirement on use of
UncheckedAccount
andAccountInfo
.edit: Unless the account has a seeds or init constraint in the account attribute.
Safety checks are run as part of the
extract_idl
function so they will run onanchor build
oranchor idl parse
commands. The extract IDL step comes aftercargo build-bpf
in the build command so this doesn't prevent the program from being built. We could do some additional things like remove the built program if it errors but it seemed a bit heavy handed.There's also a flag for Anchor.toml:
I thought this might be handy for some of the tests (e.g.
auction-house
) but probably won't document it in case it gets used all the time. 🤣Accompanying doc PR here.
Closes #1387