Stream: t-compiler/wg-rls-2.0

Topic: Types showing as !


eryn (Nov 03 2019 at 11:06, on Zulip):

Hey sorry if this is a known issue but I ran into a problem where items imported from a crate have methods that show as returning ! or {unknown}. The code works fine when compiled but rust-analyzer just shows the types incorrectly in the IDE. This is the crate specifically https://docs.rs/scrap/0.5.0/scrap/. Just wondering where the problem is and if it's with my setup is there any way I can fix this?

Florian Diebold (Nov 03 2019 at 12:15, on Zulip):

rust-analyzer does its own name resolution and type inference, which isn't yet completely correct in some cases. That said, ! and {unknown} are very different cases; {unknown} can easily happen when we can't resolve something e.g. because of some macro that we can't handle yet, whereas I would expect ! to wrongly show up only in some edge cases with e.g. match or if within a function body, not as the return type of a method.

We would have to look at the specific cases for more detail; it's possible or even likely that they're related to a known limitation, but it's hard to tell in this generality :slight_smile:

eryn (Nov 03 2019 at 12:24, on Zulip):

Makes sense

The return from this function here https://docs.rs/scrap/0.5.0/scrap/struct.Capturer.html#method.frame is being displayed as Result<!, {unknown}>

Florian Diebold (Nov 03 2019 at 12:57, on Zulip):

As far as I can see, we can't even resolve scrap::Capturer, presumably because of all the conditional compilation going on there, so that type probably comes from how it's being used, and if you e.g. do a match on the Result where you return on the Err branch, that'll lead to inferring ! for the Ok type

Florian Diebold (Nov 03 2019 at 13:00, on Zulip):

ah, it uses build.rs to set some cfgs... I doubt we can handle that at the moment, so none of them is set, hence we don't resolve anything in there (since it doesn't have a fallback implementation)

Florian Diebold (Nov 03 2019 at 13:01, on Zulip):

we used to kind of handle this better before we implemented the support for cfg we currently have...

eryn (Nov 03 2019 at 19:20, on Zulip):

Is there a way I can help it along and sort of assert what type something is just within the context of rust-analyzer? Even doing let capturer: Capturer = Capturer::new(display).unwrap(); makes it say {unknown}, shouldn't it be able to know that it's a Capturer since I set the type explicitly in the assignment?

Daniel Mcnab (Nov 03 2019 at 19:21, on Zulip):

That suggests that it can't resolve capturer, which is pretty much the same issue.

Daniel Mcnab (Nov 03 2019 at 19:31, on Zulip):

So the only way around it that I can see is to define your own Capturer with the minimum interface that you need, perhaps as a new type struct around the real Capturer

Florian Diebold (Nov 03 2019 at 20:07, on Zulip):

In this case, we don't know Capturer at all because we never even include any of the modules that define it

Last update: Nov 19 2019 at 18:40UTC