The RFC seems to be about something else, about making code annotated with cfg
only callable from code compatible with that cfg
, no matter what, which is not the case currently.
I am not sure, but maybe the distinction std
/no_std
isn't sufficient for all cases. Many crates would end up in no_std
, while having different compatibilities.
My specific problem is that I want to compile a crate to web assembly, i.e. something like wasm32-unknown-unknown
or wasm32-wasi
, but the crate has dependencies which are not compatible with those targets. The goal now is to make those dependencies compatible, but it is very laborious to find all crates which cause the incompatibility, because I need to manually compile each crate to see if it compiles on that target.
It would be helpful if I could immediately see which targets a crate was explicitly (not) designed for, so that cargo could maybe even list all of the crates which are incompatible with the target you are trying to compile to. An output like this would be useful:
The following dependencies are not compatible with target 'wasm32-unknown-unknown':
├── reqwest v0.10.7
│ ├── hyper v0.13.7
│ │ ├── h2 v0.2.6
│ │ │ ├── tokio v0.2.22
│ │ │ │ ├── mio v0.6.22
│ │ │ │ │ ├── net2 v0.2.34
│ │ │ │ │ │ └── libc v0.2.76
│ ├── hyper-tls v0.4.3
│ │ ├── native-tls v0.2.4
│ │ │ ├── openssl v0.10.30
│ │ │ │ ├── libc v0.2.76
│ │ │ │ └── openssl-sys v0.9.58
│ │ │ │ └── libc v0.2.76
where the leaf entries of the tree are the crates causing the incompatibility, in this case only libc
. The dependent crates automatically lose compatibility, which would mean that something like non-targets
should be inherited if a dependency is used (e.g. not optional or enabled by a feature).
This would make it possible to immediately see that libc
is not meant to run on web assembly, and that you would need to find an alternative for the crates that depends on it. Right now you need to look at the compiler errors, fix them for one specific crate, try again and repeat for the next incompatible crate.