Add std flag

[heytdep]

What

Adds a new feature and disables allocator when std flag is set.

Why

Allows to use the std while having a custom allocator.

Known limitations

N/A

[dmkozh]

This can be breaking for someone, can't it? No-one would have the new feature enabled, so handle_panic may disappear suddenly. Wouldn't it be safer to add a feature that disables handle_panic on-demand?

[leighmcculloch]

There's a variety of situations that we could support, and so I'm not sure using 'std' as the name of this feature is most appropriate because of the possible variety of interpretations.

Here's a matrix of configurations that could be supported. Only the two configurations with text in there are the ones currently supported. The text in the boxes is the feature enabled to get those things. Today we have:

	no allocator	sdks allocator	custom allocator	libstd allocator
sdk panic handler	default	alloc
custom panic handler
libstd panic handler

If this PR is merged, the result would be support for:

	no allocator	sdks allocator	custom allocator	libstd allocator
sdk panic handler	default	alloc
custom panic handler	std
libstd panic handler

If we wanted to support all these things, we could add the following features:

	no allocator	sdks allocator	custom allocator	libstd allocator
sdk panic handler	default	alloc	alloc-custom	alloc-std
custom panic handler	panic-handler-custom
libstd panic handler	panic-handler-std

To that end, I think this PR's new feature could be named panic-handler-custom, because the feature is disabling the built-in panic handler, and leaving it up to the developer to provide the panic handler in some way, either by importing a lib that contains one like libstd, or providing their own.

[leighmcculloch]

@heytdep Circling back onto this because we're doing some assessment if there's a need for std support with contracts that get deployed to chain.

Most of std is stubbed on wasm targets, and we're currently exploring building contracts to a different wasm32 target that doesn't yet exist but @graydon is proposing. There's some details here, but it's possible the target won't ship with a std at all:

• Wasm minimal features target rust-lang/compiler-team#791

Is the change in this PR so that libstd can be used with contracts and deployed on chain? What's the reason for doing that, or what's not available without it?

[heytdep]

@leighmcculloch sorry for seeing this late. I think this pr can be closed overall. The initial reason for this was because we're compiling the soroban sdk within the zephyr sdk (which compiles with std) to allow working with soroban types within you data flows (which works like a charm!). This pr was to enable that without having to rely on the allocator forced by the soroban sdk when the std flag was enabled, but we eventually decided that using the soroban-packed allocator is fine.

Regarding the new target not compiling with std, that shouldn't be a problem assuming the sdk doesn't change and limits functionality depending on the target (so everything should be fine assuming we can still compile the current sdk functionality within an std-dependant zephyr program and target the current wasm target without the sdk locking features behind the new proposed target).

I'm not advocating for std use on-chain (also because wasmi, especially when run onchain, is generally not suited for the memory-intensive tasks that the std would probably be used for)

[leighmcculloch]

Thanks for returning to share more details on the use.

Regarding the new target not compiling with std, that shouldn't be a problem assuming the sdk doesn't change and limits functionality depending on the target (so everything should be fine assuming we can still compile the current sdk functionality within an std-dependant zephyr program and target the current wasm target without the sdk locking features behind the new proposed target).

This is notable feedback. Admittedly not hearing feedback like this I would have likely put a compiler error into the sdk if used with the wasm32-unknown-unknown target so as to prevent folks accidentally building and distributing .wasm files built with an incompatible target. But keeping this in mind I think we can deal with that in other ways without needing to fix the sdk to a specific target. The stellar contract build command will be updated to build to target wasm32v1-none when it's released, and that should be enough along with documentation.

Thanks @heytdep.

[heytdep]

Great, thanks for taking this into account! Lmk if I can help on my end fwiw. I don't think limiting builds to wasm32v1-none is the best way to deal with this as it's really limiting for use cases besides on-chain deployments and it would make the assumption that wasm32-unknown-unknown is always an unsupported target which is incorrect.