Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix bug that somehow std is compiled into eDSL smart contracts #33

Closed
Robbepop opened this issue Mar 15, 2019 · 3 comments
Closed

Fix bug that somehow std is compiled into eDSL smart contracts #33

Robbepop opened this issue Mar 15, 2019 · 3 comments
Labels
A-ink_lang [ink_lang] Work item C-bug Something isn't working

Comments

@Robbepop
Copy link
Collaborator

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.

@Robbepop Robbepop added C-bug Something isn't working D-easy A-ink_lang [ink_lang] Work item labels Mar 15, 2019
@Robbepop
Copy link
Collaborator Author

As it seems 7d135a6 fixes this issue. Will keep it open for some time if we find other sources of std.

@Robbepop
Copy link
Collaborator Author

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.

@Robbepop
Copy link
Collaborator Author

Robbepop commented Aug 8, 2019

Fixed long time ago. Closed.

@Robbepop Robbepop closed this as completed Aug 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ink_lang [ink_lang] Work item C-bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant