-
Notifications
You must be signed in to change notification settings - Fork 69
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
Splitting contract impls across modules leads to errors #1321
Labels
bug
Something isn't working
Comments
I believe I have a fix that requires no breaking changes: |
I still have an issue to resolve on how to resolve the contract client. So change is still a WIP. |
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 10, 2024
### What Add a new trait `ContractFunctionRegister` that wraps the existing `register` function that all contracts use to create a table of all their functions. ### Why When a contract is registered with the test environment it uses the table of functions to know what functions a contract has defined. Today contract functions get added to the table by using the ctor crate to call the `#mod::register` function where `#mod` is a generated module at the same location as where the `#[contract]` macro gets used. The problem with this, and that was reported in #1321, is that it's valid in Rust to place type implementations anywhere in a crate that is able to reference the type, but there's no way for the generated code to know what relative or absolute path to use to reference that `#mod`. The generated code assumes that the `#mod` is imported into the current scope, which it never will be because users have no reason to manually do it because it is hidden from them and they don't know it exists. This situation leads to the following error that makes little sense to a developer because it refers to hidden generated code: ``` use of undeclared crate or module `__Contract_fn_set_registry` ``` Most of the time when folks add additional `impl` blocks to a type they will import the type into the current module so as to reference it, and so we can improve the existing situation by shifting the call to `#mod::register` to be a call to `Contract::register`. To ensure that the `register` function does not clash with a contract function that may also be named `register` the function is defined on a hidden trait, `ContractFunctionRegister`, and is only used in the context of that trait. There are some other minor changes included that remove assumptions about the type name of a contract being a simple identifier, so that when it is more than an identifier, such as a path (e.g. `path::Identifier`), the full type name is preserved everywhere it is needed. Close #1321
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version are you using?
v21.5.1
What did you do?
Cargo.toml
:src/lib.rs
:src/feat1.rs
:src/feat2.rs
:What did you expect to see?
Compiled successfully, and test successfully.
What did you see instead?
After adding in these lines to
feat1.rs
andfeat2.rs
:Build worked fine, but
cargo test
failed:The text was updated successfully, but these errors were encountered: