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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions