Stream: t-compiler/rust-analyzer

Topic: Testing nested functions in hir_ty

Jonas Schievink [he/him] (Mar 05 2021 at 17:48, on Zulip):

It looks like we can't write a test like this in hir_ty:

trait Tr {
    fn method(&self) -> u8 {}

impl Tr for () {}

fn outer() {
  //^^^^^^^^^^^ u8

    fn inner() {
      //^^^^^^^^^^^ u8

This causes this unwrap to fail, because it expects the function to be inside the main module. Is there any other way to do this than to copy all the source-to-def machinery from hir to hir_ty? (hir_def seems more logical, actually)

Jonas Schievink [he/him] (Mar 05 2021 at 17:54, on Zulip):

I suppose I could come up with some hack, but at that point using source-to-def seems like the better option

Jonas Schievink [he/him] (Mar 05 2021 at 18:06, on Zulip):

Hmm, I could copy module_at_position from hir_def, but that duplicates code too

Jonas Schievink [he/him] (Mar 05 2021 at 18:11, on Zulip):

Looks like module_for_file is also duplicated. Maybe we want to expose the hir_def TestDB and reuse it in hir_ty?

matklad (Mar 06 2021 at 13:37, on Zulip):

Yeah.... that's a tough design question. It feels like some part of source2def machinery does really belong to hir, but it is unclear which precise semantics we want there

matklad (Mar 06 2021 at 13:38, on Zulip):

I'll try to think about this today. Basically, what I really want is to keep hir 100% precise, but s2d is somewhat lossy

matklad (Mar 09 2021 at 20:28, on Zulip):

I'll try to think about this today.

did happen :(

Jonas Schievink [he/him] (Mar 09 2021 at 20:58, on Zulip):

For now, I went for check_infer instead, which just prints all types in all (nested) functions

Last update: Jul 27 2021 at 22:30UTC