Support cfg features generated by build scripts

[AlyoshaVasilieva]

Environment

• IntelliJ Rust plugin version: 0.2.110.5742-193-dev
• Rust toolchain version: 1.39 stable
• IDE name and version: IntelliJ IDEA 2019.3 beta 2
• Operating system: Windows 10 x64

Problem description

Ctrl-clicking function in specific circumstance takes me to wrong function. Experimental macro expansion engine is enabled.

Steps to reproduce

Cargo.toml:

[package]
name = "bug-repro"
version = "0.1.0"
authors = ["Alyosha Vasilieva <1284317+AlyoshaVasilieva@users.noreply.github.com>"]
edition = "2018"

[dependencies]
indexmap = "=1.3.0"
digest = "=0.8.1"

main.rs:

use indexmap::map::IndexMap;

fn main() {
    let mut map = IndexMap::new();
    map.insert("key", "value");
}

IndexMap::new is highlighted as error with "Unresolved reference: `new`".

Ctrl-clicking IndexMap, despite being highlighted red, correctly takes me to its declaration.

Ctrl-clicking new incorrectly takes me to the new function inside impl<D: Input + FixedOutput + Reset + Clone + Default> Digest for D, part of the digest crate.

Compilation works and gives no warnings or errors.

[artemmukhin]

This issue is caused by the fact that indexmap uses custom has_std cfg option (which is actually populated by build.rs via the autocfg crate).

The declarations of IndexMap look like this:

#[cfg(has_std)]
pub struct IndexMap<K, V, S = RandomState> { ... }
#[cfg(not(has_std))]
pub struct IndexMap<K, V, S> { ... }

Currently, IntelliJ Rust only supports some standard cfg options (for more information #4488), so has_std option isn't evaluated. That's why both declarations of IndexMap is used during name resolution.

[Undin]

Now there is a way to collect info about generated items including generated cfg option while project refresh action. Under the hood, it uses cargo check so it may significantly increase refresh time (especially, in the first time when it has to compile all dependencies).
It's disabled by default for now. To turn it on, enable org.rust.cargo.evaluate.build.scripts option in Experimental Features dialog. The dialog can be found via Help | Find Action

[Undin]

I don't think it should be closed until the corresponding feature is disabled by default

[MSxDOS]

cc #4809

FYI, #4734 will fix your issue without disabling cfg evaluation

It didn't work for winapi. I'm still getting Cannot find declaration to go to for properly imported and visible items unless I disable org.rust.lang.cfg.attributes 😞

[MSxDOS]

@vlad20012 902942a removed org.rust.lang.cfg.attributes and thus irreversibly broke the plugin for me.

[vlad20012]

@MSxDOS Oh, I'm sorry, will be fixed by #5186

[vlad20012]

@MSxDOS, please, try the nightly IntelliJ Rust plugin (see instructions), #5186 is included there

[MSxDOS]

@vlad20012 All good now, thank you.

[aschmolck]

I've had no luck getting IndexMap to work even after switching on the experimental org.rust.cargo.evaluate.build.scripts option mentioned above and invalidating the caches. As the indexmap author indicates, this appears to be a intellij-rust specific problem (indexmap-rs/indexmap#148), vscode with rust-analyzer works fine. I have experienced similar issues with at least one other crate (vscode intellisense works fine, intellij-rust fails completely) , but indexmap happens to be a dealbreaker for a particular piece of code I'm working on with a few colleagues, since we use it heavily. We'd either have to vendorize and adapt the code in some way to avoid confusing clion/intellij-rust, or switch away from intellij-rust.

Anything we can do to work around or help resolve this issue?

For what it's worth, the versions I am using are: IntelliJ Rust plugin version: 0.4.147.3871-211, Rust toolchain version: 1.51.0 stable, IDE name and version: Clion 2021.1.2, Operating system: Ubutu 20.10 and the version of indexmap is v1.6.2.

[Undin]

@aschmolck Could you provide code where the plugin doesn't work, please?

I've tried something very simple like

use indexmap::IndexMap;

fn main() {
    let map = IndexMap::<i32, i32>::new();
    let option = map.get(&1);
}

and it works, i.e. types are inferred and methods are suggested

[aschmolck]

@Undin thanks, so it appears something in addition to plain indexmap usage is needed to trigger the problem -- I will try to boil it down to a small self-contained example where completion breaks. Is the above with the default IDE config, or did you enable org.rust.cargo.evaluate.build.scripts?

[Undin]

Is the above with the default IDE config, or did you enable org.rust.cargo.evaluate.build.scripts?

I enabled org.rust.cargo.evaluate.build.scripts. Otherwise, the plugin sees two definitions of IndexMap that breaks the analysis

[MSxDOS]

It didn't work for winapi. I'm still getting Cannot find declaration to go to for properly imported and visible items unless I disable org.rust.lang.cfg.attributes

No change since then, still broken for winapi.

[aschmolck]

For what it's worth, although org.rust.cargo.evaluate.build.scripts didn't originally resolve my problem, in current versions of clion it works fine for me (crates like indexmap that use conditionally compilation in some of the signatures now have correct autocompletion after enabling the flag).

[ens-scmeeu]

In case it is helpful for others, this worked for me in the 2022.2 version of IntelliJ Community as well.