Function-local types are not resolved

[lnicola]

fn main() {
    struct S;
    let _s = S;
}

Same for type aliases. Found in #1549.

[matklad]

Yeah, we just don't support local items at all yet :(

[flodiebold]

See #1165.

[crumblingstatue]

Funny, the original example now seems to resolve, but not if it's a record struct.

[lnicola]

Hmm, maybe #2600 partially implemented this.

Actually, record structs work too, but not e.g. arrays of them. Actually nope.

[crumblingstatue]

It doesn't work, at least for me.
I did the array thing because if I just do let foo = Bar{};, it shows nothing instead of {unknown}. But if you hover over it, it will still say {unknown}.

[ice1000]

It doesn't work, at least for me.
I did the array thing because if I just do let foo = Bar{};, it shows nothing instead of {unknown}. But if you hover over it, it will still say {unknown}.

Can you fix this?

[lnicola]

It doesn't work, at least for me.

I think you're right. I wonder why unit and tuple structs work but not record ones.

Can you fix this?

I wish :-).

[pksunkara]

I am not sure if this is the same issue or not, but my gut says it is. Please correct me if I am wrong and I will create a new one. In the below working code, a.foo() doesn't resolve to a type. As you can see impl A { fn foo() } is actually inside a dummy mod. (This is one of pattern some derives use to reduce share some common stuff without exposing it to the user).

[lnicola]

Yeah, it looks like the same issue.

[flodiebold]

That (a local impl used outside that block) is actually a special case that might never be supported by RA, and IMO should be deprecated in the language. We don't want to have to parse all function (or constant) bodies just because they might contain an impl that we need; this would have a bad impact on lazyness.

This is one of pattern some derives use to reduce share some common stuff without exposing it to the user

If the impl is only used in that block, that's fine, but I don't see the point otherwise.

[pksunkara]

I agree about the impact but I think we should partially support this, i.e. only if we encounter them in const items.

I don't think there's another way to solve the issue of scoping restrictions in expanded proc-macros.

[flodiebold]

I don't think there's another way to solve the issue of scoping restrictions in expanded proc-macros.

Again, I don't see the point. Note that we certainly want to support using impls defined in the same block. But if you're relying on the fact that impls in blocks are available outside of that block, I don't see how that's solving any scoping issue.

[jonas-schievink]

Fixed by #7614 / #7627

The issue with const _: () = { ... }; that @pksunkara mentioned is now tracked in #7550