program-entrypoint: Add no_std attribute

[sonicfromnewyoke]

Problem

Currently the program-entrypoint crate is no_std "friendly" but does not have the crate attribute and used reexports from core and alloc in std

Solution

• Add the #![no_std] attribute to the crate.
• use direct import from core and alloc instead of reexports from std

[febo]

Looks good – just one nit.

[febo]

Looks good, thanks!

[LucasSte]

Adding no_std to entry point means that a #[panic_handler] must be implemented for the crate, since panics won't be processed in the STD;

[febo]

Adding no_std to entry point means that a #[panic_handler] must be implemented for the crate, since panics won't be processed in the STD;

Good point! When the custom_panic_default is used, it is not a problem since that macro brings the std – e.g., it uses msg!. But we should consider the case for when it is not used. We could either add a nostd_panic_default macro, or we need to document this case so when the program using the macro is no_std, it will need to set one up.

cc: @joncinque

Need to consider the potential issue with the panic handler.

[LucasSte]

Adding no_std to entry point means that a #[panic_handler] must be implemented for the crate, since panics won't be processed in the STD;

Good point! When the custom_panic_default is used, it is not a problem since that macro brings the std – e.g., it uses msg!. But we should consider the case for when it is not used. We could either add a nostd_panic_default macro, or we need to document this case so when the program using the macro is no_std, it will need to set one up.

cc: @joncinque

I believe my new panic implementation will solve this issue: #142

[joncinque]

If I understand correctly, since the new panic handler doesn't use msg!, I think that means this problem would get worse, since the default panic handler doesn't pull in std.

@febo is the solution to do the same thing as in pinocchio? Ie

mod __private_panic_handler {
    extern crate std as __std;
}

[febo]

Adding no_std to entry point means that a #[panic_handler] must be implemented for the crate, since panics won't be processed in the STD;

Good point! When the custom_panic_default is used, it is not a problem since that macro brings the std – e.g., it uses msg!. But we should consider the case for when it is not used. We could either add a nostd_panic_default macro, or we need to document this case so when the program using the macro is no_std, it will need to set one up.
cc: @joncinque

I believe my new panic implementation will solve this issue: #142

Unfortunately no. When you build your program as no_std, we need to set a #[panic_handler]. When the std is present, what we actually set is a panic "hook", which has the same signature but don't have the #[panic_handler] attribute.

There is a bit more comment on this here: #12 (comment)

[febo]

If I understand correctly, since the new panic handler doesn't use msg!, I think that means this problem would get worse, since the default panic handler doesn't pull in std.

@febo is the solution to do the same thing as in pinocchio? Ie

mod __private_panic_handler {
    extern crate std as __std;
}

This is the fallback for cargo test/bench/clippy, since most of the time they will link the std so we can't add a #[panic_handler].

We need to offer a "nostd" panic handler, which sets a #[panic_handler]. This is how pinocchio does it: https://github.com/anza-xyz/pinocchio/blob/main/sdk/pinocchio/src/entrypoint/mod.rs#L266-L305

Anyone can set their own one, since you really need to be explicit to make your program no_std. Even if we provide one, it needs to be added when the program is "fully" no_std - it is all a bit messy since you can write your program as no_std but when one of your dependencies bring the std you don't need to set one and the default will work fine.

In a way, having the crate as no_std does not cause a problem immediatly, just enables someone to end up a missing panic handler when they make their program no_std. At that point, they can set one, but we should include an implementation to facilitate that.

[joncinque]

In a way, having the crate as no_std does not cause a problem immediatly, just enables someone to end up a missing panic handler when they make their program no_std. At that point, they can set one, but we should include an implementation to facilitate that.

What's the best way to facilitate that? Is it something we do in this PR by including a panic handler along with an allocator?

[sonicfromnewyoke]

What's the best way to facilitate that? Is it something we do in this PR by including a panic handler along with an allocator?

i'd prefer this approach. However, we have to be sure there is no place where panic handler can be additionally provided