Skip to content

failed inference on complex nested, generic closures #6338

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

Open
elindsey opened this issue Oct 23, 2020 · 7 comments
Open

failed inference on complex nested, generic closures #6338

elindsey opened this issue Oct 23, 2020 · 7 comments
Labels
A-ty type system / type inference / traits / method resolution S-unactionable Issue requires feedback, design decisions or is blocked on other work

Comments

@elindsey
Copy link

This is a somewhat complex case. On this line: https://github.com/TimelyDataflow/timely-dataflow/blob/master/timely/examples/wordcount.rs#L32

rust-analyzer fails to infer the types for input/output (showing "unknown"), and thus fails to infer most of the types in the rest of that closure as well. RLS handles this case correctly.

That example has nested closures and a multitude of generics in that call; I've tried coming up with a more minimal repro but have so far failed. Enabling server-side logging didn't turn up any errors, so I'm not entirely sure where to go from here.

Does that pattern look like something that's a currently known failure? If not, do you have any tips on other logging or methods of looking into rust-analyzer's processing to try to determine what exactly is tripping it up?

@flodiebold flodiebold added the A-ty type system / type inference / traits / method resolution label Oct 23, 2020
@flodiebold
Copy link
Member

flodiebold commented Nov 1, 2020

I think we're hitting the (arbitrary, maybe too small) goal size limit here. We should probably increase it when other Chalk performance problems (i.e. primarily #6432) have been solved.

(To debug this, I mostly ran RA_LOG=hir_ty::traits=info CHALK_DEBUG=debug CHALK_PRINT=yes rust-analyzer analysis-stats -o main_xxx ., having renamed the main function to main_xxx to be able to analyse that single one, and having commented out everything later in the function to reduce the log size a bit.)

@umanwizard
Copy link
Contributor

@flodiebold I am a colleague of @elindsey and also involved with a project that heavily uses timely-dataflow. This issue is a big pain point for me, so I'm willing to tolerate rust-analyzer being slow or using a lot of memory if it solves the issue.

I'll try compiling r-a from source myself and bumping up that 30 number; do you have any suggestions on what to set it to? (If not, I can just try something huge and report my findings)

@flodiebold
Copy link
Member

You'll be able to set it by env variable once #6597 is merged. I'd suggest just doubling it and seeing whether that helps.

@umanwizard
Copy link
Contributor

Is there an easy way to set env vars for rust-analyzer in vscode? (Other than setting serverPath to a wrapper script that sets the environment and then invokes the binary)

@flodiebold flodiebold added the S-unactionable Issue requires feedback, design decisions or is blocked on other work label Dec 21, 2020
@flodiebold
Copy link
Member

@umanwizard You could just set the env variable in the environment for VSCode.

@lnicola
Copy link
Member

lnicola commented Apr 8, 2021

There's also rust-analyzer.server.extraEnv.

@umanwizard
Copy link
Contributor

@lnicola I don't think that existed when I posted that message :) anyway, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ty type system / type inference / traits / method resolution S-unactionable Issue requires feedback, design decisions or is blocked on other work
Projects
None yet
Development

No branches or pull requests

4 participants