You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When compiling a smart contract with the eDSL one currently can experience that parts of the standard library are compiled into the resulting binary. Things like the panicking infrastructure are using their std components. This is bad since we do not support std environments in Wasm smart contracts.
What could cause problems is that cargo is incapable of having different crate features for different paths to the same crate dependency in the dependency tree, cargo tree. Instead cargo will use the same crate features for the same crate all over the place. Since pdsl_lang, the proc_macro that itself validly makes use of std components is using pdsl_core and pdsl_model with their respective std feature flag set, it might be that the resulting final binary that also depends on pdsl_core and pdsl_model has the std flag set as well. Further investigations are needed.
The text was updated successfully, but these errors were encountered:
The newest problem of no_std incompatibility stems from depending on pdsl_core from pdsl_lang.
This caused problems with duplicate panic infrastructure since pdsl_lang brings its own since it is a proc_macro and compiles with Rust's standard library while pdsl_core is a no_std library by default that brings with it also its own panic infrastructure if compiled for no_std. Since cargo restricts crate dependencies for having shared crate features among the entire dependency tree we are not allowed to compile pdsl_core with std crate feature to fix this bug since then all other sources of pdsl_core in the entire dependency tree would also invalidly be compiled with this feature.
To fix this we had to create a new utility sub-crate called pdsl_utils that, for now, has the components that are required by pdsl_lang which is the hash module for keccak hashes. Later we can use this pdsl_utils module for other functionality that can be shared among pdsl_lang and other pDSL sub-crates.
When compiling a smart contract with the eDSL one currently can experience that parts of the standard library are compiled into the resulting binary. Things like the panicking infrastructure are using their std components. This is bad since we do not support
std
environments in Wasm smart contracts.What could cause problems is that
cargo
is incapable of having different crate features for different paths to the same crate dependency in the dependency tree,cargo tree
. Insteadcargo
will use the same crate features for the same crate all over the place. Sincepdsl_lang
, theproc_macro
that itself validly makes use of std components is usingpdsl_core
andpdsl_model
with their respectivestd
feature flag set, it might be that the resulting final binary that also depends onpdsl_core
andpdsl_model
has thestd
flag set as well. Further investigations are needed.The text was updated successfully, but these errors were encountered: