Stream: t-compiler/wg-incr-comp

Topic: HygienicIdent abstraction


view this post on Zulip cjgillot (Jan 07 2021 at 17:25):

@Vadim Petrochenkov, related to your PR #80765:
I have a branch embryo (a bud?) introducing an HygienicIdent abstraction, for just Symbol + SyntaxContext.
The objective was originally to make progress on span-less HIR.
Are you interested? Do you have use cases with more immediate applications?

view this post on Zulip Vadim Petrochenkov (Jan 08 2021 at 21:38):

I've seen this message but didn't have a chance to answer in detail yet.
SyntaxContext still contains more data than necessary on a "good path" (e.g. info about expansions of transparent and semi-transparent macros), we should be able to do better.

view this post on Zulip cjgillot (Jan 08 2021 at 21:45):

What's the minimal amount of information that is required for this?

view this post on Zulip Vadim Petrochenkov (Jan 14 2021 at 18:34):

Let me clarify the basics. So the general idea is that:

view this post on Zulip Vadim Petrochenkov (Jan 14 2021 at 18:38):

I think the most important thing here is to confirm that full Span is indeed not used on good path, because if it is used then the whole scheme breaks and we are simply slowing things down and make them more complex without any benefit.
This property is highly non-obvious, for example in #73996 we naively assumed that types are not pretty-printed on good path (with path shortening such pretty-printing calls a very heavy query), but that turned out to not be true at all.

view this post on Zulip Vadim Petrochenkov (Jan 14 2021 at 18:40):

For spans one obvious case is debuginfo - it it's generated, then full spans are used. How do you plan to deal with this case?

view this post on Zulip Vadim Petrochenkov (Jan 14 2021 at 18:46):

Regarding the minimal amount of information, it's SyntaxContext with normalize_to_macros_2_0 applied, that's what is needed for resolving names of associated items (which is always done on "good path").
After lowering to HIR unnormalized SyntaxContext should only be used for 1) "are we in external macro?" checks in lints and 2) edition checks (if I'm not forgetting anything).

The lint checks can probably be performed last, only in cases when we are sure that we are going to report the lint otherwise.
The post-AST-lowering edition checks need some audit and review, I'm not sure how often they are done and on what paths.

Anyway, full unnormalized SyntaxContext should be a good first approximation to the HygienicIdent (which I would probably call just hir::Ident).

view this post on Zulip Vadim Petrochenkov (Jan 14 2021 at 18:47):

One more thing - IIRC, some HIR nodes only use Idents due to span locations, not hygiene, they can be turned into simple Symbols without SyntaxContexts if span locations are outlined.

view this post on Zulip simulacrum (Jan 14 2021 at 18:58):

Vadim Petrochenkov said:

For spans one obvious case is debuginfo - it it's generated, then full spans are used. How do you plan to deal with this case?

worth calling out panic! and every unwrap()/expect() (track_caller method), too, in terms of location information - which is not controllable by user

view this post on Zulip cjgillot (Feb 06 2021 at 16:00):

Thanks for this detailed explanation.
I don't have a satisfactory design for storing the full span for each Ident.
1/ The simplest solution would be to add some "hir::IdentId" (as a newtype for HirId or a more compact representation) and store everything out of the tree (= a side table). This would lead to a lot of churn in downstream crates.
2/ Another solution would be to try some hybrid between storing the HygienicIdent in-tree and its span out. This would require some ident_span: HirId -> Span map. Unfortunately, some HIR nodes have Idents and no HirId.
I tend to favour solution 2, since there is already an ident_span metadata output. Since it will be sparse, I imagine using the same kind of method as for attributes.


Last updated: Oct 21 2021 at 20:03 UTC