use alloc::boxed::Box instead of the builtin Box

[NikoPit]

uses alloc::boxed::Box instead of Box
this ensures that this crate works on no_std environment

fixes #295

[NikoPit]

aparently that broke std, im working on fixing that

[NikoPit]

now it was fixed

[A4-Tacks]

As a proc-macro library, no_std should be meaningless

[NikoPit]

not really, check #295 , its generated codes refrences Box directly instead of alloc::boxed::Box, which doesnt work in no_std environment

[A4-Tacks]

There is a method similar to extern crate alloc as std here

And introducing new alloc feature doesn't seem necessary

[NikoPit]

when i just do alloc::boxed::Box it just breaks std environment, and i cant really find a better way then using a feature (since there is no things like #[cfg(no_std)])

[A4-Tacks]

Part of the code can be expanded to {extern crate alloc; alloc::boxed::Box::...}

But your PR is still breaking, because different dependencies in workspace will union features, which may potentially disrupt dependencies

Like:

• crate foo dependencies async-trait
• crate bar dependencies async-trait features alloc

So async-trait enable alloc in foo and bar, breaking in crate foo

[A4-Tacks]

In summary, the old code works well and does not require consideration of absolute paths.
Users only need to import Box

And consider the possibility of use Arc as Box

[NikoPit]

well thats basically the problem, the user isnt supposed to import Box, the crate should do it (atleast imo)

[NikoPit]

ok i realized im dumb or smth, closing ig