Make "atomic-polyfill" an optional dep for thumbv6m-none-eabi only

[therealprof]

... otherwise any crate using heapless will automatically add all the
funny ARMv6-M only dependencies regardless.

Signed-off-by: Daniel Egger daniel@eggers-club.de

[therealprof]

Noticed while trying to update the heapless dependency in nushell that atomic-polyfill, bare-metal and more started showing up in the Cargo.lock.

[Dirbaio]

What's the reason for making atomic-polyfill thumbv6m-only in the first place?

atomic-polyfill already does the detection of whether polyfilling is required itself. On platforms with native atomics it'll just reexport core::sync::atomic. It can be used unconditionally, it does the right thing.

If it was used unconditionally, heapless would gain support for more polyfilled archs for "free" when they're added to atomic-polyfill.

[therealprof]

What's the reason for making atomic-polyfill thumbv6m-only in the first place?

No idea.

If it was used unconditionally, heapless would gain support for more polyfilled archs for "free" when they're added to atomic-polyfill.

Fair enough, but there're crates using heapless on a regular CPU and depending on atomic-polyfill seems to trigger cargo to include bare-metal, embedded-hal, nb and whatnot in the dependency chain which is quite undesirable. I was trying to bump heapless from 0.6 to 0.7 but I'm pretty sure the maintainers will not appreciate the additional baggage coming with that change...

[Dirbaio]

atomic-polyfill seems to trigger cargo to include bare-metal, embedded-hal, nb and whatnot in the dependency chain which is quite undesirable

indeed... Maybe it should be fixed in atomic-polyfill instead, I'll take a look

[Dirbaio]

Okay: atomic-polyfill is pulling in cortex-m on thumbv6m only already.

Dependencies specified with [target.thumbv6m-none-eabi.dependencies] still appear on Cargo.lock even for non-v6m targets. I think it's because Cargo does version resolution for all targets together. For non-v6m targets, v6m-only deps don't appear in cargo tree and don't get built.

That might be causing the confusion? something appearing in Cargo.lock doesn't mean it's in the dependency tree for the current target.

[therealprof]

Not sure what exactly is happening, it's very opaque...

However this PR still adds the ability to opt out of the atomic-polyfill dependency if the cas feature is not enabled.