Recently, I am trying to run some open source static analyzer (e.g., Rudra). However, I found that the nightly toolchain used by these works are always conflicted with the crates due to the version requirements of dependencies. From my knowledge, this issues happen because static analyzers used the rustc_private APIs, which are still not stable. In the case, that the APIs are still not stabilized, is there a unified solution to run these static analyzers on our projects without pain so far?
Are you saying that your project only compiles with a nightly toolchain version which differs from the one the analyzers use? In that case, there is not much to be done other than changing your project so it does not require nightly features.
Or, are you saying that you are getting conflicts between different nightly versions used by different analyzers? Then, please show us the details of the failure so we can advise on how to improve the situation.
I'm not OP obviously, but I ran into similar tooling that needed some older nightly, but I used features from a stable version newer than that nightly. I think in my case it was the 2024 edition that I depended on (this was a while ago, don't remember exactly).
As I have a reasonable MSRV of N-1, I often see things like this with tooling that depend on a fixed nightly.
1 Like
Sorry for making you confused. The static analyzers requires these cargo projects to use a fixed nightly version; therefore, causing to conflicts.
The errors would be like,
error: package `home v0.5.11` cannot be built because it requires rustc 1.81 or newer, while the currently active rustc version is 1.72.0-nightly
and we need to manually do such kinds of things,
cargo update -p home@0.5.11 --precise 0.5.9
for each conflicts which is very time-consuming
Yes. Correct. I think there have been several works published now. So I am thinking about whether there are already some solutions.
In one sense, the answer here is: the analyzer is using a stale version of rustc, and it needs to be updated so people like you can use it without problems. Tools need to be maintained.
However, there are tools that you can use to improve the situation. As of 1.84, Cargo has “MSRV-aware dependency version resolution” — if you set in your project
[package]
rust-version = "1.72"
edition = "2024"
then cargo update and related commands will avoid adding or updating packages to versions that are declared incompatible with 1.72. (I'm not sure whether cargo update will downgrade for you once you add this configuration; if not, you'll still have to do your manual updates, but they will stick around for future use.)
While this feature is new in 1.84, the Cargo.lock file it produces will still be usable in older versions, so it’s fine that your goal is to be compatible with 1.74.
In general, these internal compiler APIs are never going to be stable because the compiler needs freedom to change things.
That said, there are projects like GitHub - rust-lang/project-stable-mir: Define compiler intermediate representation usable by external tools to make a more-stable way to consume things that won't be broken quite as much.
1 Like