Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nightly clippy hangs on nalgebra crate #13373

Closed
nsjvidana opened this issue Sep 9, 2024 · 3 comments
Closed

Nightly clippy hangs on nalgebra crate #13373

nsjvidana opened this issue Sep 9, 2024 · 3 comments
Labels
C-bug Category: Clippy is not doing the correct thing

Comments

@nsjvidana
Copy link

Summary

I was a little skeptical of making an issue on a specific crate, but I believe that other crates that are similar to nalgebra might be impacted by this. When running nightly clippy on a crate that uses the nalgebra crate (version 0.33.0), clippy hangs on the nalgebra crate and never finishes checking it. As of right now, I have only tested this on a machine running Windows 10 with the latest version of nightly clippy.

Things that I have tried and their outcomes:

  • run stable clippy (nothing went wrong)
  • run nightly clippy on the nalgebra crate repo (clippy hanged at nalgebra here as well)
  • run stable clippy on the nalgebra crate repo (clippy worked, but there were a lot of warnings)

Reproducer

Steps to reproduce:

  1. run cargo init in an empty folder
  2. run cargo add nalgebra
  3. run rustup run nightly cargo clippy

I expected to see this happen:
Clippy finishes running in a reasonable amount of time (~13s with stable clippy on my machine).
Instead, this happened:
Clippy stayed stuck on checking nalgebra and never finished. I waited for over an hour and it never finished.

Version

rustc 1.83.0-nightly (12b26c13f 2024-09-07)
binary: rustc
commit-hash: 12b26c13fba25c9e1bc2fdf05f3c2dbb851c83de
commit-date: 2024-09-07
host: x86_64-pc-windows-msvc
release: 1.83.0-nightly
LLVM version: 19.1.0

Additional Labels

No response

@nsjvidana nsjvidana added the C-bug Category: Clippy is not doing the correct thing label Sep 9, 2024
@smoelius
Copy link
Contributor

smoelius commented Sep 9, 2024

The hang is reproducible with cargo +nightly check, so I think the problem is in the compiler itself.

In a stack trace, these two functions appear repeatedly:

#1  0x00007ffff....... in <&rustc_middle::ty::list::RawList<(), rustc_middle::ty::generic_args::GenericArg> as rustc_type_ir::fold::TypeFoldable<rustc_middle::ty::context::TyCtxt>>::try_fold_with::<rustc_next_trait_solver::canonicalizer::Canonicalizer<rustc_trait_selection::solve::delegate::SolverDelegate, rustc_middle::ty::context::TyCtxt>> ()
   from $HOME/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-67e992fc9ebdf5ae.so
#2  0x00007ffff....... in <rustc_next_trait_solver::canonicalizer::Canonicalizer<rustc_trait_selection::solve::delegate::SolverDelegate, rustc_middle::ty::context::TyCtxt> as rustc_type_ir::fold::TypeFolder<rustc_middle::ty::context::TyCtxt>>::fold_ty () from $HOME/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/librustc_driver-67e992fc9ebdf5ae.so

With the Clippy in master (0ee2650), there is a noticeable delay of about 10 seconds, but Clippy does eventually finish.

(Sorry, I didn't debug further.)

@smoelius
Copy link
Contributor

smoelius commented Sep 9, 2024

Just happened upon this by coincidence: rust-lang/rust#130056

@Jarcho
Copy link
Contributor

Jarcho commented Sep 11, 2024

Closing as this is a rustc issue.

@Jarcho Jarcho closed this as not planned Won't fix, can't repro, duplicate, stale Sep 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: Clippy is not doing the correct thing
Projects
None yet
Development

No branches or pull requests

3 participants