Simplify atomics using lazy

[tamird]

No description provided.

[josephlr]

We can't unconditionally include lazy. It will cause breakage on platforms without AtomicUsize.

[tamird]

Which platorms, please? Are they not included in CI?

[josephlr]

Interesting, well it used to be the riscv32imc platforms (which do not have atomics). However, for some reason lazy.rs is building, even on a target like riscv32imc-unknown-none-elf which definitely doesn't have atomics. I'll investigate furthur.

[josephlr]

Remove this, we only want #[allow(dead_code)] on certain methods in the error module.

[tamird]

There are only two pub (crate) items on the error module and prior to this change they are both marked allow(dead_code). Which methods do you not want this on?

[newpavlov]

I am not convinced that we should "simplify" the NetBSD backend by reusing the lazy module. The current code is fairly straightforward and self-contained, I don't see significant issues with it.

This PR also introduces a lot of other IMO unnecessary changes out of scope for the purpose declared in the PR title.

[tamird]

Sure, I can break it up into more PRs if you folks prefer. I was just looking for ways to make things a bit more neat. Anyway, I used a macro to introduce LazyPtr which I think works nicely now.

[briansmith]

I am not convinced that we should "simplify" the NetBSD backend by reusing the lazy module. The current code is fairly straightforward and self-contained, I don't see significant issues with it.

At least, I don't see how this change makes things easier to understand. The additional abstraction with the macros makes things harder to understand.

This PR also introduces a lot of other IMO unnecessary changes out of scope for the purpose declared in the PR title.
Sure, I can break it up into more PRs if you folks prefer.

+1.

[tamird]

I am not convinced that we should "simplify" the NetBSD backend by reusing the lazy module. The current code is fairly straightforward and self-contained, I don't see significant issues with it.

At least, I don't see how this change makes things easier to understand. The additional abstraction with the macros makes things harder to understand.

This PR also introduces a lot of other IMO unnecessary changes out of scope for the purpose declared in the PR title.
Sure, I can break it up into more PRs if you folks prefer.

+1.

I'll mark this as draft - said other changes were in #760 (now #763)

[newpavlov]

Closing per my comment above.