Stream: t-compiler/help

Topic: type-relative paths in lowering


Taylor Cramer (Apr 19 2019 at 22:24, on Zulip):

Does anyone familiar with the resolver know why expr_std_path can't resolve type-relative paths? I get an error when trying to use it with std::pin::Pin::new_unchecked (works fine with e.g. std::ops::Try::into_result, but that's an associated method of a trait, not a type)

Taylor Cramer (Apr 19 2019 at 22:25, on Zulip):

Is this limitation fundamental? My temporary workaround plan is to introduce an unstable feature-gated fn std::pin::new_unchecked and call that instead, but I'd prefer to avoid introducing hacks if unnecessary.

Taylor Cramer (Apr 22 2019 at 22:05, on Zulip):

ping-- anyone know about this? maybe @Vadim Petrochenkov ?

Vadim Petrochenkov (Apr 22 2019 at 22:55, on Zulip):

expr_std_path is a module-relative resolution thing.
It's too early to resolve type-relative paths at that point.

Vadim Petrochenkov (Apr 22 2019 at 22:56, on Zulip):

You can actually make a partially resolved path during lowering and put it into HIR.

Vadim Petrochenkov (Apr 22 2019 at 22:56, on Zulip):

And it will be resolved during type checking.

Vadim Petrochenkov (Apr 22 2019 at 22:58, on Zulip):

std::pin::Pin can be fed to std_path, then the last segment added as hir::QPath::TypeRelative

Vadim Petrochenkov (Apr 22 2019 at 22:59, on Zulip):

Actually, ExprKind::Range desugaring works that way already.

Vadim Petrochenkov (Apr 22 2019 at 23:00, on Zulip):

(To clarify, std::ops::Try::into_result is module-relative because traits and enums are modules in the eyes of name resolution.)

Last update: Nov 11 2019 at 23:15UTC