I have run into this situation a few times, so it might in part be a me-problem, but I can't imagine I am completely alone in this.
When inadvertently importing the std-lib into a no_std project through a dependency, the error message is not very helpful. It typically spews hundreds of errors stating that any use of std is not supported, which in itself feels like incorrect behavior. Then I have to scroll up past all these messages to see where in the compilation it failed. In many cases it failed compiling the dependency of a dependency, meaning I have little idea where in my dependency imports I messed up.
On my latest experience with this, it only told me <Std-violating dependency> failed to compile, but not which dependency made use of it. I had to resort to cargo tree -i <Std-violating dependency> to narrow down where in my dependency tree it could have failed.
I think there must be a better way to present this information. I imagine something like the following, where the tree between the std-violator and my crate is shown, and (if possible) if there are any obvious features which can be enabled/disabled to prevent std from reaching my crate.
Your dependency <Your dependency> has an upstream inclusion of "std" through <Std-violating dependency>, which is not supported in <Your project>. Try setting default-features = false for your import of <Your dependency> in Cargo.toml.
<Your project> v0.1.0
└── <Your dependency> v0.1.0 <- try setting `default-features = false`
└── <Some other dependency> v0.2.0
└── <Std-violating dependency> v1.1.0 <- relies on std-functionality