Hi @matklad , I'm looking into adding better support for the
alloc traits when analyzing a project that uses
core is especially tricky because its
extern crate core; statement is added by
We can solve this outside of RA by just including
alloc as automatic dependencies in all roots, even if unused. Though it is adding unnecessary dependencies for the vast majority of crates.
I was wondering if it would make sense to have them specialized in
rust-project.json since they're not included in the list of externs passed to rustc. Either through some kind of flag or matching by name.
So, it’s not „them“, it’s „sysrroot crate don‘t have to be explicitly specified on he command line“. rust-analyzer deliberately lacks the concept of sysroot and requires every dependency to be explicit. So, just adding them to all te crates is how this should work
Ok, and I assume that means there's no harm in leaving in, for example,
std in a
no_std context. Is that a safe assumption to make?
Yup, that is a safe assumption
hmm, couldn't it influence import path generation?
I think you can
extern crate std in an otherwise
Yes, you can explicitly import any sysroot crate.
#![no_std] just disables the implicit
extern crate std and changes the prelude to refer to libcore instead of libstd.
the import path code looks at presence of
#![no_std] to decide which crate to prefer
On embedded targets libstd literally is not present though
Ok, so our assumption that we can just directly provide
std as deps for all crates in
rust-project.json is the correct path forward?