RustRover 2024.2 EAP Compatibility

[farces]

Hello,

The plugin version/compatibility matrix lists RustRover 2024.2 as supported, however enabling the plugin prevents the current project from being closed (if one was open), and when creating and opening a new project the IDE throws an error before it's able to read the project structure. Switching ZigBrains off and restarting the IDE lets the project load, but re-enabling ZigBrains causes the same symptoms to reoccur.

Looking at the files created the only thing that looks odd is that the toolchain home directory for Zig is relative to the project path instead of being absolute (it is absolute under languages configuration in RR), but I don't think that's related: <option name="toolchainHomeDirectory" value="$PROJECT_DIR$/../../zig/zig-windows-x86_64-0.14.0-dev.1057+76f062690" />

The Zig project created by RustRover doesn't look like it has had zig init run on it either, but doing that manually doesn't resolve the issue unfortunately.

The errors point to an internal IDE function getSourceRoots() failing:

[79681fe1] Failed to execute task com.intellij.util.indexing.UnindexedFilesScannerExecutorImpl$ScheduledScanningTask@40261211

java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.NullPointerException: getSourceRoots(...) must not be null

OS: Windows 11 Zig: 0.14.0-dev.1057 ZLS: 0.14.0-dev

[farces]

Checked a few other issues on this project and found this note about relative paths:

Originally posted by @FalsePattern in https://github.com/FalsePattern/ZigBrains/issues/56#issuecomment-2251223985

I went and changed the stdlib path from the default to override and manually selected the stdlib path and everything works now. Seems like the default path selection might not be working correctly, maybe not in all cases but for mine at least.

My project structure for reference is: Project: D:\code\RustProjects\zigtest Zig root: D:\code\zig\zig-windows-x86_64-0.14.0-dev.1057+76f06269

And as mentioned in the issue it looks like toolchainHomeDirectory in zigbrains.xml is relative to the project path, and I assume stdlib was the same.

This was my configuration prior to the change showing the zig path should have been absolute, and I'd have expected stdlib to have matched that:

[FalsePattern]

Should be fixed in 17.1.0

[farces]

Have tested 17.1.0 and can confirm it works however I had to delete my .idea directory, reload RustRover and reconfigure paths for the plugin; just updating actually broke my working config from 17.0.0 (with override stdlib path to be absolute), and redoing paths under Languages->Zig wasn't resolving it.

Actually it looks like this hasn't resolved my issue, the first time I load a project and set the zig paths for the plugin it's completely fine (which it wasn't on 17.0.0), but closing and reopening RustRover gets me back to the same error. Switching back to a manual path override resolves it.

[anna-hope]

Just to add a data point, I am using macOS and RustRover 2024.1.8, and also experiencing an issue (project won't load), with the same workaround @farces provides (manually setting the Zig stdlib path).

[FalsePattern]

Should be properly fixed in 17.2.0.