fix: Look for enum variants and trait assoc functions when looking for lang items

[Veykril]

Examples for lang enum variants are the Option variants.
Assoc trait functions aren't being seen since they aren't declared in the direct module scope.

[matklad]

bors r+

I wonder why Option needs to be a lang item though?

[bors]

Build succeeded:

• Rust (macos-latest)
• Rust (ubuntu-latest)
• Rust (windows-latest)
• TypeScript (ubuntu-latest)
• TypeScript (windows-latest)

[Veykril]

Good question, Result's variants are also lang items so imagine it might be due to ? being more special cased back then? at least from what I remember it had a very specific desugaring, might be wrong.

[Veykril]

Interesting, they were added for AST lowering purposes rust-lang/rust#75145

[matklad]

Interesting! So that means that we might want to change hir_def::Expr::Path to point either to an unresolved path, or to a resolved def.

I don't think we do a lot of desugaring today, we have an explicit Expr::For, Expr::Try etc. Instead, all those are handled explicitly in the type inference, and that's where we need to get "known" items.

I think that's the right pattern -- AST-based desugaring is a nice thing in theory, but, in practice, it doesn't save that much effort. And the lowering shape in rustc, which has this awkward effect of needing both unresolved and resolved paths in the same data type, feels like an evidence for awkwardness of lowering.

At this point, it seems that it's better to carry the surface syntax as is through the type-inference, and then, in a single step, resolve all names and simplify things to some core language.