I'd like to use rust-analyzer on this repo: https://github.com/nrf-rs/nrf-hal/
The problem is that it contains a big, shared crate, nrf-hal-common, that uses non-additive Cargo features. The workspace also contains a bunch of crates that enable precisely one of those features and reexport the resulting library contents. This causes r-a to think it has to enable all features when running
cargo check and performing analysis, which breaks with the way the shared crate is designed.
Is there any way to fix this, or would we have to implement more advanced features, like on-the-fly
#[cfg] modification to get this to work?
(I could live without check-on-save, but at least IDE functionality would be nice)
This is similar to what @Paul Faria has been looking at, around configuration mgmt in the rust-project.json -based flows. I think we'd need more complex handling of
cfg than we currently have (either on-the-fly, or multiple instances of a crate in the db based the features that were enabled as it was encountered in the dependency tree.
It's actually handling them generically internally, but have different UI at the IDE interface. Though this case is different from what I was considering in use cases. I was taking into consideration different features toggled on and off as the "active" configuration. This is about having different features active at certain points in the crate graph, right @Jonas Schievink?
Oh wait. I think this is also a limitation of cargo. I have a similar scenario in coi where I have to manage my tests with makefiles because the workspace as a whole requires all of the features to match at the top level.
I missed the detail about the workspace
I think what I'm working on might help in that case. I actually hadn't gotten to the point where I'd considered workspaces yet but this will be helpful when I get there.
cargo check does not work if you do it on the nrf-hal workspace. I don't really mind that, since it still works fine in the individual subcrates. Mostly I just want r-a's IDE features.
I might implement on-the-fly switching of features/cfgs then (just for r-a, not Cargo)
Oh, that's what I'm currently working on :grinning_face_with_smiling_eyes:
Ah, alright, go ahead then :)
cargo check is unfortunately unfixable. The best we can do is to override check on save command to
cargo check -p p1 && cargo check -p p2 && cargo check -p p3 etc
Our own analysis... that's tricky
I think this is a different problem than the one @Paul Faria is working on :-) Or at least, there are two orthogonal problems
The second is:
ie, it is the problem of creating a CrateGraph out of cargo metadata.
I think the second one should be more straightforward to fix, by only changing
Specifically, we currently eagarly activate all features of all packages present in
cargo metadata. I think we can fix that to activate only some features, and fork internal packages as needed
Ideally, we'd just ask Cargo for unit-graph (cargo metadata 2.0 in the works), but we can hack this manually