Change active cfg's dynamically

[tweksteen]

I am raising this issue following the conversation on wg-rls-2.0 (topic "Support for #[cfg(test)]").

The test cfg option is currently added unconditionally when loading the source of a crate. A similar approach is usually followed for project using the rust-project.json model.

It is a standard pattern for mocking library to use the attribute: #[cfg(not(test))]. Because of this, the name resolution (i.e. go to definition) will jump to the mocked value instead of the original one.

For the rust-project.json-based model, it is possible to declare the crate with and without the configuration enabled. We should support the configuration selection, as provided by the client, to use one or the other crate. We may use the initializationOptions during the initialize request to provide rust-analyzer with the information on which configuration should be enabled.

@woody77 @Nashenas88 @flodiebold Did I miss anything from the conversation? Thanks.

[Nashenas88]

I think you covered it pretty well. I had intended to start on this but threw out my back a few weeks ago, and moving to a new apartment this week, so I haven't been able to spend extra time at my desk outside of normal work hours. I'll be jumping back into rust-analyzer work next week after all the moving is done 😃 .

[Nashenas88]

The approach I was intending to take here is to allow selection of configurations within a single file. As @tweksteen mentioned above, there's a big difference between the ways that Cargo.toml and rust-project.json lay these out. The former lists them explicitly, while the latter has implied configurations in the cases where a file is available in multiple crates compiled with different settings. For example, in a rust-project.json project, a crate compiled with #[cfg(test)] enabled is a separate binary from one compiled with #[cfg(not(test))], i.e. they are separate entries in rust-project.json.

The way I wanted to approach this was to first get an interface in place that returns a list of configurations when given some input file. Given the above differences, I would imagine that the implementation for these would be different depending on whether you had a Cargo.toml project or a rust-project.json project. The implementation for Cargo.toml project would return multiple options that could be toggled on and off, while the rust-project.json project would simply provide a list where one item can be chosen. Any concerns with this approach?

Then I'd follow this up with some UI work, with the layout here still TBD. I haven't done VS Code interface work in a few years so I imagine I'd lean on someone else or take a bit to catch up. I don't personally intend to work on the emacs or vim interfaces since I don't use them for development purposes myself (I think someone more invested would come up with a better interface than I could).

[tweksteen]

Any concerns with this approach?

No, that sounds good!

Then I'd follow this up with some UI work, with the layout here still TBD. I haven't done VS Code interface work in a few years so I imagine I'd lean on someone else or take a bit to catch up. I don't personally intend to work on the emacs or vim interfaces since I don't use them for development purposes myself (I think someone more invested would come up with a better interface than I could).

Thanks to the LSP specs, we should be able to find a solution that is generic enough, and easy to derive for each editor. I suggest to start by finding out how this configuration option would look like at the specs level (initializationOptions? as I mentioned earlier). What message will be send to the LSP server to update it?. Once that's defined, I'd be happy to help for the integration with Vim.

[woody77]

For example, in a rust-project.json project, a crate compiled with #[cfg(test)] enabled is a separate binary from one compiled with #[cfg(not(test))], i.e. they are separate entries in rust-project.json.

I think this is just an artifact of our process, but it does uncover a spot where rustc and cargo both diverge a bit, in that cargo is managing a library and/or set of binaries built from the same sources, and rustc produces a single binary.

And then RA is trying to bridge that by having #[cfg(test)] always enabled, so that test code is properly parsed, but really on one hand, it should be doing a parallel test/no-test analysis. On the other hand, being explicit about which configuration(s) you want active is probably the better approach, especially in a large workspace.

That all being said, I think your suggested approach is the right one for rust-project.json, because it's the closest in semantics to what a Cargo.toml file provides: A set of enabled-feature constraints. And then this becomes the start of being able to interact with those.

Does the RA VSCode extension provide the workspace (and general VSCode) configuration of RA via initializationOptions?

[Nashenas88]

Posting a quick update: Not too much progress made, but I do have a small branch up with some initial changes. Moving took up most of my time last week (still had to make a few trips back to the old place during the week/weekend) so I didn't get as far as I'd hoped. I'll be out of town from Wednesday night until next Monday, so I also don't expect to get much done this week. I do expect to ramp up significantly next week, though.

Regarding initializationOptions, it's set directly from the rust-analyzer section of the relevant config, see https://github.com/rust-analyzer/rust-analyzer/blob/b5272573300766d0c8417161c1a4f959abc9ff43/editors/code/src/client.ts#L40

[matklad]

Yeah, we should have some kind of way to say "don't enable test". Not sure what's the best way to achieve that. Perhaps we need some kind of cfg_overrides config which we'll use when converting cargo metadata / projec.json to CrateGraph?

The open question here is "how do I identify a crate?", as there are no globally unique names.

[Nashenas88]

@matklad The approach I was going to take would differ between rust-project.json and Cargo.toml. With the former, we could simply list which crates have configurations for some active file (since there is a possibility for one file to belong to multiple crates), while with the latter, we should know which crate we're in and whether there are controllable features, right? I.e. we know which crates a file belongs to, and we know which crates come from the top-level Cargo.toml entries, right?

My thought was to tie tests with feature selection for Cargo.toml projects since it's the same from the point of view of needing to change the Analysis, right?