Prefer intrinsics and primitives in core

[richardeoin]

Rather than the equivalent exports from std

See https://doc.rust-lang.org/core/index.html

Useful for creating no_std crates, and is completely equivalent in other
cases. There are still some features that require std, using these in a
no_std crate will error at compile time (the current behaviour).

Mark the cpp crate as no_std

[ogoffart]

Thanks or the patch.
This looks quite good.
However, tere are still some usage of std:: in cpp/src/lib.rs
I guess they should be removed before marking the crate as no_std.

[ogoffart]

There is also one use of ::std::sync::Once in the cpp_macro generated code. That needs std. But maybe the crate can still be marked as no_std even if it it stays.

[richardeoin]

The no_std meta in cpp/src/lib.rs actually applies to almost nothing. The macros are expanded in the user's crate, and it doesn't propagate into the cpp_macros crate because that is marked with:

[lib]
proc_macro = true

But still they can be replaced with core at no cost, I will do that.

As you say there's no trivial replacement for ::std::sync::Once, but this is only occurs if expanded into the user's crate (through the use of the rust! macro, I think). So much of this crates functionality can be used by no_std crates anyhow.

[ogoffart]

Thank you !

[ratijas]

I'd like to note that while the PR is good in itself and mostly works in the wild, it was released under patch version bump despite being a breaking change (woboq/qmetaobject-rs#108) — which is bad.

Incompatibility arise from the fact that in Rust 2015 edition using ::core paths require explicit extern crate core; line at the top of the main.rs file, while ::std paths work out-of-the-box.

I probably should open a new issue with a request for updated documentation regarding 2015 edition, or write such PR myself...