Flowistry panics if you open any .rs file in vscode not in SourceFiles

[nico-abram]

If you have a .rs file that's not reachable/compiled for the target flowistry uses (I assume the host?), flowistry opens a window with this error message in vscode:

Flowistry could not run because your project failed to build with error:
thread 'rustc' panicked at 'called `Result::unwrap()` on an `Err` value: Could not find SourceFile for path: d:\dev\rs_playground\src\test.rs. Available SourceFiles were: [src\main.rs, src\other.rs, C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\libc-0.2.116\src\lib.rs, C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\libc-0.2.116\src\macros.rs, C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\libc-0.2.116\src\fixed_width_ints.rs, C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\libc-0.2.116\src\windows\mod.rs, C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\libc-0.2.116\src\windows\msvc\mod.rs]', D:\.cargo\registry\src\github.com-1ecc6299db9ec823\flowistry_ide-0.5.18\src\spans.rs:35:8
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: could not compile `rs_playground`

Backtrace:

Stack backtrace:
   0: std::backtrace::Backtrace::disabled
   1: std::backtrace::Backtrace::capture
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <rustc_lint::BuiltinCombinedPreExpansionLintPass as rustc_lint::passes::EarlyLintPass>::check_foreign_item_post
   7: <rustc_driver::args::Error as core::fmt::Debug>::fmt
   8: <rustc_lint::BuiltinCombinedPreExpansionLintPass as rustc_lint::passes::EarlyLintPass>::check_foreign_item_post
   9: <rustc_lint::BuiltinCombinedPreExpansionLintPass as rustc_lint::passes::EarlyLintPass>::check_foreign_item_post
  10: rustc_driver::pretty::print_after_hir_lowering
  11: std::sys::windows::thread::Thread::new
  12: BaseThreadInitThunk
  13: RtlUserThreadStart', D:\.cargo\registry\src\github.com-1ecc6299db9ec823\flowistry_ide-0.5.18\src\spans.rs:35:8

It should be reproducible with any project, just create an new empty .rs file in vscode, open it, and turn flowistry focus mode on and off. Note that if the file actually contains rust code, flowistry will also panic if you open that file while in focus mode and place the cursor somewhere such that it tries to analyze it.

This can be annoying in a codebase using conditional compilation for different modules/files, for example:

#[cfg(target_arch = "x86_64")]
mod x86_64;
#[cfg(target_arch = "x86_64")]
use x86_64 as arch;

#[cfg(target_arch = "aarch64")]
mod aarch64;
#[cfg(target_arch = "aarch64")]
use aarch64 as arch;

fn main() {}

Where both x86_64.rs and aarch64.rs contain some valid rust code:

fn f() -> () {
    ()
}

Opening aarch64.rs and placing the cursor on the return type panics with the same general error, on my x86_64 machine.

Tested only with the vscode marketplace extension on windows 10 21H2

[liquidev]

Another case where this happens is within crates that are in the workspace. In Mica I have the implementation split into multiple crates for better separation, and Flowistry panics for every crate that isn't mica.

[willcrichton]

Thanks for the reports, I will investigate this.

[willcrichton]

I just changed Flowistry's behavior so it won't pop up an annoying window when it can't find your file. Instead, it will show a little question mark:

This feature was released in 0.5.30.

I realize it doesn't solve the underlying issue of actually getting Flowistry to find the files, which I will continue to work on.

[GRAYgoose124]

Compiling the most recent release(0.5.3) yields a strange bug, where preload fails, but clicking the flowistry button causes it to work until I go into my examples folder. So, I presume this is a similar issue, but I haven't investigated it deeply.

I'm trying to use flowistry on a project that is the most recent nightly (1.66), which has stabilized mixed_integer_ops, so my build flow/source can't have a #![feature(mixed_integer_ops)] embedded. Again, if I build using cargo, or with my CI, I get no issues on 1.66.0.

I'm fairly sure this is some issue with setting the toolchain environment. None of my TOOLCHAIN env vars are set in in a regular terminal, not sure if you're internally setting those. I'm on arch. I have a rust-toolchain.toml defaulting to nightly.

Again, I just came across this and haven't really wrapped my head around it, as I've encounted a few similar seeming iterations, so I'll just paste the most recent experience log I've had related to this issue. If you need me to try to repeat it, or more information, let me know: flowistry_bug.md

[willcrichton]

@liquidev I just checked and was able to run Flowistry in mica/mica-cli, so I think this issue should be fixed?

@GRAYgoose124 unfortunately this is an unavoidable issue. Flowistry uses a specific nightly to analyze your code. I try to update Flowistry such that the latest Flowistry nightly can always analyze code from the latest stable Rust release. However, if you're writing nightly Rust code, then you may get ahead of the Flowistry nightly.

There isn't a way to ask Flowistry to use a specific nightly, because it relies on the Rust compiler API which changes between nightlies. The only real solution is that Flowistry would be a "component" distributed with the Rust compiler toolchain, similar to Clippy / Rustfmt / and so on. But that might be a hard sell to the Rust lang devs!