include! concat! env! OUT_DIR not auto completing in cargo workspace

[chinedufn]

Related to #4482, I've never had the OUT_DIR support work in my project.

I've created a new repository to demonstrate the issue.

https://github.com/chinedufn/rust-analyzer-issue-5040

In the screenshot below I expected crate1:: to autocomplete with HELLO, the name of the generated constant from the build.rs in the bottom left.

Instead there are only crate1::{super,self} as options for completion.

Load out dirs is checked

\cc @flodiebold @edwin0cheng

[bjorn3]

Do you have "rust-analyzer.cargo.loadOutDirsFromCheck": true set?

[chinedufn]

Yup! Just updated my issue comment to explicitly show that, thanks!

[chinedufn]

I’m on nightly-2020-06-22

[kiljacken]

From my brief run in with how we do VFS glob matching, the issue might be that generated does not have the .rs file extension.

[chinedufn]

I've updated the example repo to include .rs chinedufn/rust-analyzer-issue-5040@e159f6d

Still doesn't work unfortunately

[seunlanlege]

I also have this problem, are there any means of obtaining logs from the server so we can attach?

[seunlanlege]

Also it used to work for me, then I think I updated and it didn't work anymore

[ndarilek]

I'm experiencing this outside of a workspace and definitely have the setting enabled. Checking out this project, highlighting Node on line 29, and pressing F12 brings me to the lib.rs in the Rust gdnative crate, not to its definition.

Not sure if that is a different issue given the absence of a workspace, but figured it might be at least another data point.

Thanks.

[edwin0cheng]

@chinedufn I think I know what's going on in your example. Note that your example project structure is :

root
  Cargo.toml
  src/lib.rs
  crates/crate1
  crates/crate2

And the root Cargo.toml is :

[package]
name = "rust-analyzer-cargo-workspace"
version = "0.1.0"
authors = ["Chinedu Francis Nwafili <frankie.nwafili@gmail.com>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]

[workspace]
members = [
	"crates/crate1",
	"crates/crate2",
]

Note that the workspace session in root Cargo.toml is redundant, because the root crate exists. if you changed to :

[package]
name = "rust-analyzer-cargo-workspace"
version = "0.1.0"
authors = ["Chinedu Francis Nwafili <frankie.nwafili@gmail.com>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
crate1 = {path="crates/crate1"}
crate2 = {path="crates/crate2"}

Then the problem you mentioned will be solved.

[edwin0cheng]

OTHO, I think it is some bug in cargo-metadata for this situation or it is by design ?

[edwin0cheng]

@ndarilek I think it is working now, I remember I fixed some bugs in previous weeks related on that.

[ndarilek]

No, sorry, not with the latest rust-analyzer as of yesterday. For instance, placing my cursor over `SpeechSynthesizer` in https://github.com/ndarilek/tts-rs/blob/master/src/backends/winrt.rs#L25 just loads lib.rs: include!(concat!(env!("OUT_DIR"), "/winrt.rs")); It doesn't take me to the definition.

[chinedufn]

@edwin0cheng thanks for looking into this!

The use case for members instead of dependencies is so that the root crate does not have a bunch of dependencies that it does not need.

You could get around this by just not using the root crate so that you can give it bogus dependencies, as I think you're proposing, but then if you use something like cargo build --all you're building and linking a potentially massive root crate that you don't actually use for anything.

With that in mind I think it would be better if this worked with a crate that uses [members]. That would lead to less surprises, I think.

Is this possible? I'm not so familiar with how all of this go-to definition and completion stuff works.

Thanks!

[edwin0cheng]

@ndarilek :

goto-definition is for include! macro is yet to implement , but it is another issue #3767

@chinedufn :

yeah, It definitely is a bug of RA , and the bug is related to how we treat the root crate dependencies. IIRC, we use "cargo check" on the workspace to fetch the OUTDIR (which is used for include! macro). Here is the related code :

https://github.com/rust-analyzer/rust-analyzer/blob/dab210d9b2d877ca9ed02bd7e0c8952d133965d3/crates/project_model/src/cargo_workspace.rs#L374-L405

Maybe 'cargo check' didn't check the members in this case ?

[chinedufn]

@edwin0cheng would cargo check --workspace do the trick, or is there much more to it than that?

[edwin0cheng]

IIUC, it should do the trick, something like this will work :

cmd.args(&["check", "--message-format=json", "--manifest-path", "--workspace"]).arg(cargo_toml); 

For the reference It is the doc from cargo help check :

By default, when no package selection options are given, the packages selected depend on the selected
manifest file (based on the current working directory if --manifest-path is not given). If the manifest is
the root of a workspace then the workspaces default members are selected, otherwise only the package defined
by the manifest will be selected.

The default members of a workspace can be set explicitly with the workspace.default-members key in the root
manifest. If this is not set, a virtual workspace will include all workspace members (equivalent to passing
--workspace), and a non-virtual workspace will include only the root crate itself.

And in your case, it is a non-virtual workspace .

[chinedufn]

Closed via #7264

[ilyvion]

I'm having an issue with a dependency that has a file that is just include!(concat!(env!("OUT_DIR"), "/timezones.rs")); (Source here) and rust-analyzer does not work with the types in this file:


etc.

I can't find any "Load out dirs" setting as mentioned in the OP. Cargo/Rust itself has no trouble using these types/functions.