subxt fails to generate for BitVec type in public API, error message too long
#1211
Comments
drahnr
changed the title
BitVec type in public API, error message too long
|
Hey Bernhard, Thanks for reaching out! Looking at the error it seems that subxt is not able to derive struct AvailabilityThresholdBitfield(pub :: subxt :: utils :: bits :: DecodedBits < :: core :: primitive :: u8 , runtime_types :: bitvec :: order :: Lsb0 > ,)However, since the Line 97 in ead9250 What I expect is happening is that we have different Codec crate dependencies which causes an incompatibility in ABIs Most substrate dependencies are using: While subxt is using I do agree indeed that the error is a bit too verbose, maybe there's something we can do about that |
|
@drahnr it might help if you could point us at a repo where you are seeing this issue; we could then check the above! Offhand I'd assume that 3.4.0 and 3.6.1 were compatible and would lead to both using 3.6.1, but perhaps there is something in this area that is causing an issue! |
|
@jsdw cannot provide source code at this time beyond with
|
The above is just the beginning, it exceeded my terminal buffer of 10000 lines scrollback. |
I think the issue here is this bit: The type that should be in use there is: This is one of the type substitutions that we do by default because the generated type doesn't "make sense" and needs to be swapped with a type that does mean something (ie implements the Order trait or whatever). So i'm not sure why it isn't occurring for you, unless you've disabled it? One vague guess I have is that you need to enable the The version of BitVec there should be fine. Hmmm... honestly I'd probably need some sort of reproducable example to be able to properly dig and work out why the type substitution isn't happening as expected (perhaps I could see how you've used the subxt macro?) |
I'm not sure how much we can help with this; it's not a subxt specific error, but just a consequence of the Rust compiler complaining about lots of code that has been generated that isn't valid. We can hopefully work out what's happening with the codegen though, and may be able to either fix it or provide warnings when something that's likely to fail is encountered re options provided. |
|
Enabling the |
|
Interesting 🤔 Would you think it would be hard to provide a minimal reproducible example? We could otherwise look at the generated code from substrate wrt the BitVec, however, that may end up not leading to this error and potentially be time-consuming |
|
Just to confirm, I built the latest And then generated code from this node by running this in the subxt root: I can see in that file that the substitutions have worked as expected, eg I see code like this: pub votes_reject: ::subxt::utils::bits::DecodedBits<
::core::primitive::u8,
::subxt::utils::bits::Lsb0,
>,And If I run this simple example with that polkadot node still running: use subxt::{OnlineClient, PolkadotConfig};
// Don't point at a URL in production:
#[subxt::subxt(runtime_metadata_url="ws://localhost:9944")]
pub mod runtime {}
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let _ = OnlineClient::<PolkadotConfig>::new().await?;
Ok(())
}Everything still works ok. So I can't find any issue offhand, and without some reproduction of the error I don't think I can do anything more here. |
|
Which version of substrate did you use? I am focused on |
My polkadot node was compiled from The version of Subxt I used was 0.32.1 (although nothing significant has changed re type substitutions for a while). During testing I also tried Can you provide some example code, with specific versions, which runs into this issue? |
|
So far testing the example:
@jsdw @lexnv |
|
I think that your issue is here: Here, you don't enable all of the default type substitutes that would normally be enabled via the You can probably fix this by using: TypeSubstitutes::with_default_substitutes("::subxt".into())(replacing "::subxt" with whatever the path that gets to the subxt crate is). These codegen APIs are somewhat undocumented and are mainly internal details; we should probably give them a general tidy so that generating code via this sort of approach exposes the same sorts of options as generating the code via the mnacro or codegen CLI option, because right now it's easy to give options like this that lead to it being a bit naff! |
|
Thank you for taking the time looking into it! I'd appreciate if you could document the codegen API a bit more, as well as providing |
Yeah, I'll open an issue for this! TBH, it's not really been part of the public interface I'd expected anybody to use because it's a bit messy in general, but I think we can probably hide most of it away and provide some sort of simple builder/entrypoint thing which allows for the same sort of configuration options as the macro/CLI tool :) |
|
I've opened #1221 to address this, so I'll close this issue now since your problem has been resolved! Thanks for raising! |
appeared in the progress of upgrading from substrate
0.9.42to0.9.43with subxt0.29as well as0.30and0.31.The text was updated successfully, but these errors were encountered: