Stream: t-compiler/rust-analyzer

Topic: Using r-a on nrf-hal

Jonas Schievink [he/him] (Oct 29 2020 at 13:30, on Zulip):

I'd like to use rust-analyzer on this repo:

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)

woody77 (Oct 29 2020 at 21:34, on Zulip):

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.

Paul Faria (Oct 29 2020 at 21:39, on Zulip):

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?

Paul Faria (Oct 29 2020 at 21:41, on Zulip):

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.

Paul Faria (Oct 29 2020 at 21:41, on Zulip):

I missed the detail about the workspace

Paul Faria (Oct 29 2020 at 21:42, on Zulip):

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.

Jonas Schievink [he/him] (Oct 29 2020 at 21:43, on Zulip):

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

Jonas Schievink [he/him] (Oct 29 2020 at 21:43, on Zulip):

I might implement on-the-fly switching of features/cfgs then (just for r-a, not Cargo)

Paul Faria (Oct 29 2020 at 21:57, on Zulip):

Oh, that's what I'm currently working on :grinning_face_with_smiling_eyes:

Jonas Schievink [he/him] (Oct 29 2020 at 21:58, on Zulip):

Ah, alright, go ahead then :)

matklad (Oct 30 2020 at 11:56, on Zulip):

I think 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

matklad (Oct 30 2020 at 11:58, on Zulip):

Our own analysis... that's tricky

matklad (Oct 30 2020 at 11:58, on Zulip):

I think this is a different problem than the one @Paul Faria is working on :-) Or at least, there are two orthogonal problems

matklad (Oct 30 2020 at 11:59, on Zulip):

One is:

The second is:

matklad (Oct 30 2020 at 11:59, on Zulip):

ie, it is the problem of creating a CrateGraph out of cargo metadata.

matklad (Oct 30 2020 at 12:00, on Zulip):

I think the second one should be more straightforward to fix, by only changing to_crate_graph function

matklad (Oct 30 2020 at 12:01, on Zulip):

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

matklad (Oct 30 2020 at 12:02, on Zulip):

Ideally, we'd just ask Cargo for unit-graph (cargo metadata 2.0 in the works), but we can hack this manually

Last update: Jul 29 2021 at 20:45UTC