Support no_std (Rust 1.64 and later)

[chrysn]

Closes: #12 (see previous discussion there).

This requires Rust 1.64 (or the version in which cstr_core gets stabilized if things do get reverted; it's already in current nightlies). I don't have any automated tests to offer for whether the result truly works without std -- I've tested it in my applications, but given how tests rely on std, it's not easy to prove no_std operation without building for a target that has no std library. Given that there are few dependencies and no extern crate std code, I don't think that this necessarily needs extra testing.

[upsuper]

Sorry but I don't quite understand this PR.

Could you explain why do we need all the things around cfg(proc_macro)? The only purpose of this crate is to provide a proc macro. I don't quite see why it needs any conditional compilation guarding that.

[chrysn]

The general reason of `cfg(proc_maro)` is that the compiler doesn't know that this is all only for the proc macro -- and would try building it not only for the host (where the progam is being built and the proc macro executed) but also for the target (on which it would eventually be run). Normally, that's no big issue -- at link time, the functions that were built only for the proc macro will just be stripped because they are unused at run time. For no_std targets, the proc macro can not be built (because it has no std, and generally the compiler wouldn't work on it), and telling that to the compiler allows building the crate for these targets. (Rethinking your comment I did find that even the crate itself, or probably more its root module, can be made conditional; I'm rewriting the more intrusive parts of the PR to that respect. PR update coming up).

[upsuper]

The general reason of cfg(proc_maro) is that the compiler doesn't know that this is all only for the proc macro -- and would try building it not only for the host (where the progam is being built and the proc macro executed) but also for the target (on which it would eventually be run).

I'm not very convinced. The compiler, or at least Cargo indeed knows that this is only for proc macro, since this is written in Cargo.toml:

cstr/Cargo.toml

Line 13 in 8357a00

proc-macro = true

If the compiler / cargo builds it for the target, it should be a bug of rustc / cargo. If there is such a bug known, you can link it here and we can proceed with it, otherwise I'd be a bit hesitant.

[upsuper]

I believe it is not a problem nowadays.

I tried to reference cstr in a test project and build it with --target=wasm32-unknown-unknown (where there is no proc macro to use), and I got:

   Compiling proc-macro2 v1.0.42
   Compiling quote v1.0.20
     Running `rustc --crate-name build_script_build --edition=2018 /home/upsuper/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-1.0.42/build.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="proc-macro"' -C metadata=d192f8c195eafe6b -C extra-filename=-d192f8c195eafe6b --out-dir /home/upsuper/tmp/testwasm/target/debug/build/proc-macro2-d192f8c195eafe6b -L dependency=/home/upsuper/tmp/testwasm/target/debug/deps --cap-lints allow`
   Compiling unicode-ident v1.0.2
     Running `rustc --crate-name build_script_build --edition=2018 /home/upsuper/.cargo/registry/src/github.com-1ecc6299db9ec823/quote-1.0.20/build.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="proc-macro"' -C metadata=b8f77f34fc485bb0 -C extra-filename=-b8f77f34fc485bb0 --out-dir /home/upsuper/tmp/testwasm/target/debug/build/quote-b8f77f34fc485bb0 -L dependency=/home/upsuper/tmp/testwasm/target/debug/deps --cap-lints allow`
     Running `rustc --crate-name unicode_ident --edition=2018 /home/upsuper/.cargo/registry/src/github.com-1ecc6299db9ec823/unicode-ident-1.0.2/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C metadata=9dd456b64e9ce577 -C extra-filename=-9dd456b64e9ce577 --out-dir /home/upsuper/tmp/testwasm/target/debug/deps -L dependency=/home/upsuper/tmp/testwasm/target/debug/deps --cap-lints allow`
     Running `/home/upsuper/tmp/testwasm/target/debug/build/quote-b8f77f34fc485bb0/build-script-build`
     Running `/home/upsuper/tmp/testwasm/target/debug/build/proc-macro2-d192f8c195eafe6b/build-script-build`
     Running `rustc --crate-name proc_macro2 --edition=2018 /home/upsuper/.cargo/registry/src/github.com-1ecc6299db9ec823/proc-macro2-1.0.42/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="proc-macro"' -C metadata=a8d9680bdaf8f761 -C extra-filename=-a8d9680bdaf8f761 --out-dir /home/upsuper/tmp/testwasm/target/debug/deps -L dependency=/home/upsuper/tmp/testwasm/target/debug/deps --extern unicode_ident=/home/upsuper/tmp/testwasm/target/debug/deps/libunicode_ident-9dd456b64e9ce577.rmeta --cap-lints allow --cfg use_proc_macro --cfg wrap_proc_macro`
     Running `rustc --crate-name quote --edition=2018 /home/upsuper/.cargo/registry/src/github.com-1ecc6299db9ec823/quote-1.0.20/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="proc-macro"' -C metadata=1296dae9da284cc9 -C extra-filename=-1296dae9da284cc9 --out-dir /home/upsuper/tmp/testwasm/target/debug/deps -L dependency=/home/upsuper/tmp/testwasm/target/debug/deps --extern proc_macro2=/home/upsuper/tmp/testwasm/target/debug/deps/libproc_macro2-a8d9680bdaf8f761.rmeta --cap-lints allow`
   Compiling cstr v0.2.10
     Running `rustc --crate-name cstr --edition=2018 /home/upsuper/.cargo/registry/src/github.com-1ecc6299db9ec823/cstr-0.2.10/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type proc-macro --emit=dep-info,link -C prefer-dynamic -C embed-bitcode=no -C debuginfo=2 -C metadata=c8a1c2870f01f17a -C extra-filename=-c8a1c2870f01f17a --out-dir /home/upsuper/tmp/testwasm/target/debug/deps -L dependency=/home/upsuper/tmp/testwasm/target/debug/deps --extern proc_macro2=/home/upsuper/tmp/testwasm/target/debug/deps/libproc_macro2-a8d9680bdaf8f761.rlib --extern quote=/home/upsuper/tmp/testwasm/target/debug/deps/libquote-1296dae9da284cc9.rlib --extern proc_macro --cap-lints allow`
   Compiling testwasm v0.1.0 (/home/upsuper/tmp/testwasm)
     Running `rustc --crate-name testwasm --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=15628e230f038961 -C extra-filename=-15628e230f038961 --out-dir /home/upsuper/tmp/testwasm/target/wasm32-unknown-unknown/debug/deps --target wasm32-unknown-unknown -C incremental=/home/upsuper/tmp/testwasm/target/wasm32-unknown-unknown/debug/incremental -L dependency=/home/upsuper/tmp/testwasm/target/wasm32-unknown-unknown/debug/deps -L dependency=/home/upsuper/tmp/testwasm/target/debug/deps --extern cstr=/home/upsuper/tmp/testwasm/target/debug/deps/libcstr-c8a1c2870f01f17a.so`
    Finished dev [unoptimized + debuginfo] target(s) in 1.48s

You can see this crate (along with all its dependencies) is not built for the wasm32 target at all.

[chrysn]

The wasm32-unknown-unknown target is a bad test case because it does have a std library. It's a common issue with no_std libraries that they accidentally pull in some std components, and testing on a target with a standard library just passes.

PR #14, which I've simplified significantly based on your comments (I had misunderstood how profound effects the proc_macro = true line has) now has a test that fails when applied on its own, and succeeds once the simplest of the fixes (writing core rather than std) is applied.

Closing this as #14 is by all accounts the better fix.