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
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-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.