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

slh-dsa: fix multiple AsBytes definitions #846

Closed
wants to merge 1 commit into from

Conversation

erdnaxe
Copy link
Contributor

@erdnaxe erdnaxe commented Aug 16, 2024

For some reasons, I got the following build error while using slh-dsa in a no_std project:

[...]
error[E0252]: the name `AsBytes` is defined multiple times
  --> /home/user/.cargo/git/checkouts/signatures-f73d5010bc56a463/cfda25f/slh-dsa/src/address.rs:23:5
   |
22 | use zerocopy::AsBytes;
   |     ----------------- previous import of the macro `AsBytes` here
23 | use zerocopy_derive::AsBytes;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^ `AsBytes` reimported here
   |
   = note: `AsBytes` must be defined only once in the macro namespace of this module

For more information about this error, try `rustc --explain E0252`.
error: could not compile `slh-dsa` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...

I don't really understand why cargo test in RustCrypto/signatures/slh-dsa works fine. Here is a proposition for a fix, but maybe there is a cleaner way to address this issue ?

@tarcieri
Copy link
Member

It seems like the problem here is that zerocopy conditionally re-exports zerocopy_derive::AsBytes when its derive feature is enabled, but slh-dsa is not enabling it.

What probably happened @erdnaxe is some other crate in your project enabled the zerocopy/derive feature, triggering the re-export.

If you explicitly enable zerocopy's derive feature, then it should re-export the zerocopy::AsBytes derive macro, making the direct dependency and imports from zerocopy-derive unnecessary.

tarcieri added a commit that referenced this pull request Aug 16, 2024
...rather than directly depending on `zerocopy-derive`.

This fixes problems that arise if the `derive` feature is enabled by
other dependencies in the same tree. See #846.
@tarcieri
Copy link
Member

I think #847 should take care of it

tarcieri added a commit that referenced this pull request Aug 16, 2024
...rather than directly depending on `zerocopy-derive`.

This fixes problems that arise if the `derive` feature is enabled by
other dependencies in the same tree. See #846.
@tarcieri tarcieri closed this Aug 16, 2024
@erdnaxe
Copy link
Contributor Author

erdnaxe commented Aug 17, 2024

Thank you! I confirm that it fixes the build error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants