Rename fails when type inference fails

[IceTDrinker]

rust-analyzer version: rust-analyzer version: 0.3.1850-standalone in VSCode

rustc version: rustc 1.78.0-nightly (2bf78d12d 2024-02-18)

relevant settings: nothing notable

It seems that that version of rust analyzer failed to rename some functions (via F2) where it's not able to infer the type of some variables in complex type situations (rust analyzer used to be able to infer "deeply nested types" where an iterator returns itself an iterable type which is itself iterable and returns a complex type but it stopped doing so something like 6 or 9 months ago) I don't know if it's specific to said version or if it's a more ancient problem, I just stumbled upon it recently.

[Veykril]

Can you provide an example code snippet? It is difficult to figure out the problem from just your description

[IceTDrinker]

@Veykril certainly ! give a few minutes, might even be able to use the github online vscode editor

[IceTDrinker]

Ah no, it's not available in vscode web

So if you clone https://github.com/zama-ai/tfhe-rs and checkout main and go to

Edit: we have refactors coming or commit 6828438898bc6e4564a0e74956b463a9ef9d1d97 (https://github.com/zama-ai/tfhe-rs/blob/6828438898bc6e4564a0e74956b463a9ef9d1d97/tfhe/src/core_crypto/algorithms/ggsw_encryption.rs)

tfhe/src/core_crypto/algorithms/ggsw_encryption.rs:242

the first par fork type checks properly we get the underline of the function

but line tfhe/src/core_crypto/algorithms/ggsw_encryption.rs:270 which does a very similar operation on the same type we don't get the type check and the proper underline

Basically the generator can be "forked" into an iterator of generators which will return a subset of bytes of the original generator, and it seems that the forking + the par_iter for_each throws rust analyzer off

I remember it breaking one day and I guess I did not think of posting an issue here.