There's a bug in the logic for adding external types from other crates into the idl.
The way it works is a macro that :
first checks use statements to see which crate the type is imported from'
looks for the Cargo.lock of the project
then finds the name and version of the crate in Cargo.lock
then looks for the type definition in the cargo registry for that crate locally
The bug I'm trying to fix appears in a recursive situation where a program A imports a type from crate B which uses a type from crate C.
When the macro gets expanded in crate B, it is incapable of finding the Cargo.lock of the project and panics (this is because at that point the working directory is the ~/.cargo/registry and not the anchor workspace ).
I propose to update the code so Cargo.lock is searched from the program path.
There's a bug in the logic for adding external types from other crates into the idl.
The way it works is a macro that :
use
statements to see which crate the type is imported from'The bug I'm trying to fix appears in a recursive situation where a program A imports a type from crate B which uses a type from crate C. When the macro gets expanded in crate B, it is incapable of finding the
Cargo.lock
of the project and panics (this is because at that point the working directory is the~/.cargo/registry
and not the anchor workspace ).I propose to update the code so Cargo.lock is searched from the program path.
Here's a reproducible example: https://github.com/diyahir/minimal-pyth-version-error
tic_tac_toe
, it imports the Anchor typePriceUpdateV2
from Crate Bpyth-solana-receiver-sdk
, it imports the Anchor typePriceFeedMessage
from Crate C.pythnet-sdk