What's the best way to use rust-analyzer functionalities from a client Rust application?

[nicola-gigante]

I'm trying to analyze some Rust code in a way that is not purely syntactical, needing deeper information such as name lookup, lifetime elision, etc.

In particular, one of the things I need the most is the ability to do a cross-crate lookup for a name and go to its definition, which is exactly what rust-analyzer provides for the IDEs. I've tried to come up with a hand-made solution starting from the syn package but it's a dead-end.

What's the best way to reuse the rust-analyzer implementation of these functionalities from a client application? Is the LSP protocol the only interface? Can I use it as a library and get your internal ASTs or other representations?

[ShoyuVanilla]

GitHub CodeQL repository might be a great example, especially this crate: https://github.com/github/codeql/blob/main/rust/extractor/src/main.rs (but other ones as well under rust directory)
BTW our lifetime elision is quite incomplete yet

[ShoyuVanilla]

Oh, you mean running load-cargo to itself in the build script. Yeah, that will definitely hang as load-cargo builds the build script of the target crate and that hangs due to the target directory lock as you said when invoked on itself.

[ShoyuVanilla]

I guess you might be trying to extend the compiler with custom lints/extra checks with build script but I'd recommend building it with another crate to trigger the build 😅
Or you may use a separated target dir for load-cargo to evade contention

[ShoyuVanilla]

To run load-cargo you have to set CargoConfig's target directory option to the desired value that passed to load_workspace_at and you have to configure it to not run build script - there's an option for it as well - otherwise you'll be fall into another infinite cycle that try to load cargo with running build script which causes another load cargo with running build script... So, I'd really recommend not doing this build script magic 😅

[nicola-gigante]

I see!

Now I've set CargoConfig::target_dir_config and it seems to proceed more. I get a lot of messages of proc-macro packages being built, but then it hangs anyway, probably when running my own build.rs again.

So you're probably right, I have to avoid building build.rs again. What is the option you are referring to? I don't find it in CargoConfig.

[nicola-gigante]

Ok now it works! I set an environment variable before launching cargo and I check it at the beginning to quit if I find it.

For reference, this works:

use std::path::PathBuf;

use camino::*;
use ra_ap_load_cargo::*;
use ra_ap_project_model::*;

fn main() {
    println!("cargo::rerun-if-changed=build.rs");

    if std::env::var("TEST_BUILD_RECURSIVE").is_ok() {
        return;
    }

    unsafe { std::env::set_var("TEST_BUILD_RECURSIVE", "true") }

    let path = PathBuf::from(std::env::var("CARGO_MANIFEST_PATH").unwrap());

    let load_config = LoadCargoConfig {
        load_out_dirs_from_check: true,
        with_proc_macro_server: ProcMacroServerChoice::Sysroot,
        prefill_caches: false,
    };

    let mut target = PathBuf::from(std::env::var("OUT_DIR").unwrap());
    target.push("target");

    let config = CargoConfig {
        target_dir_config: TargetDirectoryConfig::Directory(
            Utf8PathBuf::from_path_buf(target).unwrap(),
        ),
        ..CargoConfig::default()
    };

    match load_workspace_at(&path, &config, &load_config, &|msg| {
        println!("cargo::warning={msg}")
    }) {
        Ok((_db, _vfs, _macro_client)) => println!("cargo::warning=OK!"),
        Err(err) => println!("cargo::error={err}"),
    }
}

Sounds a bit hackish but analyzing my own source is a prerequisite for what I had to do.

Thanks a lot!