dylint: `cargo dylint my_lints` produces `Error: expected more input` while parsing crate versions after updating `rustc`

It seems like the error happens around here:

https://github.com/trailofbits/dylint/blob/b9002a5e8b999601326c28870b4775c5f3dfe884/dylint/src/driver_builder.rs#L107-L108

rustc -Vv:

rustc 1.54.0-nightly (5dc8789e3 2021-05-21)
binary: rustc
commit-hash: 5dc8789e300930751a78996da0fa906be5a344a2
commit-date: 2021-05-21
host: x86_64-unknown-linux-gnu
release: 1.54.0-nightly
LLVM version: 12.0.1

Lint library’s Cargo.toml:

[package]
name = "patchmixolint"
version = "0.1.0"
authors = ["Ruby Lazuli"]
description = "Set of personal lints"
edition = "2018"
publish = false

[lib]
crate-type = ["cdylib"]

[dependencies]
clippy_utils = { git = "https://github.com/rust-lang/rust-clippy", rev = "ae0d4da764fd751494fb270fd04c2c686eac1302"}
dylint_linting = "0.1.0"
if_chain = "1.0.1"

[dev-dependencies]
dylint_testing = "0.1.0"

[package.metadata.rust-analyzer]
rustc_private = true

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 20

Most upvoted comments

Yeah, cargo dylint assumes that a driver can be built “once and for all” for any given toolchain. But obviously that assumption is naive.

Thanks a lot for raising this. This is a bug.

smoelius on Dec 12, 2021

So I think I 90% understand what’s going on.

The root cause appears to be this: https://github.com/trailofbits/dylint#limitations

Dylint is trying to build embassy using a particular toolchain. But embassy has a rust-toolchain file that insists on another toolchain. When the driver is run, the presence of that rust-toolchain file causes the driver to link against some version of a library the driver doesn’t expect (this is the part I don’t completely understand). So the driver fails to execute, its output is empty, and the version parser reports that it expects more input.

The only workarounds I can see are to remove embassy’s rust-toolchain file, or edit it.

Still, there’s definitely a bug here: Dylint should notice and report that the driver failed, rather than blindly accept empty output.

Also, from our earlier conversation, the documentation should indicate that cargo-dylint cannot be installed with --debug.

Regarding inspecting cargo-dylint’s path: the problem is that the installation path can change. So I am afraid that that solution could make Dylint unusable for certain users, or could be fragile. Thanks for the suggestion, though.

I’ll the get the error handling and the documentation fixed. Thanks a lot for exposing these problems! Please let me know if I missed anything.

smoelius on Jul 12, 2021

Sure 👍 I’ve put my library on GitHub, so feel free to check for anything strange.

These look fantastic! I especially like impl_eq_for_float.

A notable thing that’s just come to mind is that I’m using channel = “nightly” in rust-toolchain to track the currently installed nightly version, which may be a bad idea.

This isn’t terrible, but I think what may eventually happen is that one of the lints or clippy_utils will fail to compile. Of course, you could wait for this to happen, and then roll back to the last compiler version where things worked.

Thanks very much for sharing and thanks for this report! Please let me know if the problem arises again.

smoelius on May 26, 2021