Skip to content

trait imports used implicitly by custom handlers are still not re-emitted into data_driver #20

@HDauven

Description

@HDauven

The current import re-emit logic for custom data-driver handlers only keeps imports whose name appears directly in the handler tokens.

That works for direct short-path cases like Vec, Error, and JsonValue, but it misses trait imports that are only needed implicitly for method or associated-function resolution after the handler is moved into the generated data_driver module.

Minimal reproduction:

#[dusk_forge::contract]
mod my_contract {
    use core::str::FromStr;
    use dusk_data_driver::Error;

    pub struct MyContract {
        value: u64,
    }

    impl MyContract {
        pub const fn new() -> Self {
            Self { value: 0 }
        }
    }

    #[contract(encode_input = "raw_id")]
    fn encode_raw_id(json: &str) -> Result<alloc::vec::Vec<u8>, Error> {
        let id = u64::from_str(json)
            .map_err(|_| Error::Unsupported(alloc::string::String::new()))?;
        Ok(id.to_le_bytes().to_vec())
    }
}

At the original site this is fine, but after the handler is spliced into data_driver, FromStr is no longer in scope and expansion fails.

So the current identifier-based filtering is too narrow for trait-based resolution. We need the re-emit logic to also preserve imports that are required implicitly by handler bodies, not just imports whose names appear literally in the handler tokens.

Expected behavior:

  • Handlers that rely on trait imports should still compile after being moved into data_driver.
  • Re-emit should cover trait-based method and associated-function resolution as well.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions