Stream: t-compiler/rust-analyzer

Topic: rust-analyzer#907

matklad (Mar 02 2019 at 20:53, on Zulip):


John Renner (Mar 03 2019 at 22:56, on Zulip):

Okay so digging into this genericparams thing. I think we need to improve the id we return in Resolution::GenericParam(u32)because it returns the index at _some_ unknown scope. which seems not what we want

matklad (Mar 04 2019 at 07:37, on Zulip):

Hm, I think keeping it just u32 should be fine, but we need to change the Resolver to return the generic scope as well

matklad (Mar 04 2019 at 07:38, on Zulip):

Like, the ExprId is also just an u32, but the resolver has a body method whihc returns the relevant scope

matklad (Mar 04 2019 at 07:38, on Zulip):

so, we can add .generics method to resolver, which adds info about generics

John Renner (Mar 08 2019 at 00:56, on Zulip):

That makes sense. I'll get cracking on that. Just a question, while we're at it, why not make body and generics part of the Resolution::{LocalBinding, Generic}. It seems odd that they methods are so linked to the specific resolver states, but not exposed that way.

matklad (Mar 08 2019 at 07:10, on Zulip):

That won't work automatically: you'll have to add lifetime parameters or add Arcs.... But in general this seems like a good idea: keep LocalBindint private to the hir crate and make a higher-level API on top of that for IDEs, sort-of like stuff in code_model works

matklad (Mar 08 2019 at 07:10, on Zulip):

hm, I think if we use code-model pattern exactly, we'll get something like this

matklad (Mar 08 2019 at 07:13, on Zulip):
pub struct LocalBinding {
    pat: PatId

impl LocalBinding {
     pub fn syntax(self, resolver: &Resolver) -> TreeArc<SyntaxPtr> {

impl Resolver {
   /*private*/ fn body()....
John Renner (Mar 08 2019 at 20:18, on Zulip):

That's a bit better, but it still has this property that you need to call LocalBinding::syntax with the same Resolver that produced it, otherwise you could get nonsense results.

John Renner (Mar 08 2019 at 20:57, on Zulip):

Though on further reflection, I'm not sure exactly what we could do better. Maybe debug asserts that they match? but anyway this is a bit of a rabbit-hole. I think the code-model pattern makes a good deal of sense

John Renner (Mar 08 2019 at 22:49, on Zulip):

Okay more digging leads me to think that generalizing Body and BodySourceMap structure may be beneficial here, because ultimately the types all work the same way, they're just constructed differently on a per item basis. Is the underlying id for PatId, ExprId, ImplId, etc. guaranteed to be unique? That is, could we unify them with a EntityIdor some such thing so that we could store them in a single map? Cuz then we could provide methods to query for the specific ast:: node you're looking for.

matklad (Mar 09 2019 at 15:12, on Zulip):

I think that long-term we do want to generalize this source-map pattern, but I am not sure it's best to do it right now. I think haven't got enough experience using them, so we are at risk of extracting a wrong abstraction .

Similarly, I feel uneasy about generic EntityId : it is possible, but we'll lose some type-safety that way. I would lean towards a type-safe trait-based solution, like AstItemDef

Last update: Jul 29 2021 at 09:30UTC