Open heytdep opened 4 months ago
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.
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