Stream: t-compiler/rust-analyzer

Topic: Dump the hir_ty level AST?


Jade (May 16 2021 at 23:13, on Zulip):

I'd like to debug https://github.com/rust-analyzer/rust-analyzer/issues/8747, for which I'd like a dump of the hir_ty AST. Is there a currently existing way to get that information out?

Jonas Schievink [he/him] (May 16 2021 at 23:18, on Zulip):

There's a "View HIR" command, but I doubt it outputs what you want

Jonas Schievink [he/him] (May 16 2021 at 23:24, on Zulip):

Is the problem that AttrDefId::FunctionId(f) => Some(f.lookup(self.db.upcast()).container.into()), doesn't get you the containing trait?

Jade (May 16 2021 at 23:27, on Zulip):

I think so, yes. I could put some logging into there again but that's my recollection. I believe the lowering is the problem because asking it to parse gets a reasonable concrete syntax tree

Jonas Schievink [he/him] (May 16 2021 at 23:36, on Zulip):

I don't think we have any debugging facilities for that, so logging is probably your best bet

Jade (May 16 2021 at 23:37, on Zulip):

i was thinking of adding one, so just wanted to make sure i wasn't missing something

Jade (May 21 2021 at 08:19, on Zulip):

I figured this out by just reading source code. So what's going on is that the container is just being set to the module. This makes sense as the module is the only container that we really know about in nameres/collector.rs in ModCollector: there is no parent information attached to the functions that I can find and we can get AST references, but there is no way to dereference them (probably by design). So I need to change the input into there. I feel like this is going to be a difficult change.

Jonas Schievink [he/him] (May 21 2021 at 09:38, on Zulip):

Hmm, do we set it to the block module or the "real" module? The collector should know about both

Jonas Schievink [he/him] (May 21 2021 at 09:39, on Zulip):

There are some bugs with how we store inner items in the ItemTree though, maybe they cause issues here

Jade (May 21 2021 at 12:08, on Zulip):

I believe that it's putting the trait functions into the block module of the containing function, rather than into the trait itself. I'm not sure if this is bad behaviour. Hopefully tomorrow I'll have a chance to compare this to a normal trait where we don't have this bug and see if it is doing something reasonable.

Jonas Schievink [he/him] (May 21 2021 at 12:15, on Zulip):

might be related to this: https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/hir_def/src/body/tests/block.rs#L156-L157

Jonas Schievink [he/him] (May 21 2021 at 16:39, on Zulip):

hmm, this seems weird, because we're definitely using the right container for trait functions here: https://github.com/rust-analyzer/rust-analyzer/blob/de403b10448e23f232804596538de92fc57203d6/crates/hir_def/src/data.rs#L156

Jonas Schievink [he/him] (May 21 2021 at 16:52, on Zulip):

Jonas Schievink [he/him] said:

There are some bugs with how we store inner items in the ItemTree though, maybe they cause issues here

Wrote down some details about this in https://github.com/rust-analyzer/rust-analyzer/issues/8911

Last update: Jul 29 2021 at 08:30UTC