Span for variant data / function arguments

[hkalbasi]

Currently, we can retrieve the span of a DefId, but not the span of its parts (e.g. fields of a struct). I guess we can easily add a span to VariantDef (I can make a PR if it is desired) but it is not the end. For getting span of the types of the fields (and nested types in their generic), rustc has the hir::Ty in addition to rustc_middle::Ty. The former is a type with syntactical presence in the source code, and contains span, and the latter is a conceptual type that is maybe generated during inference or MIR generation. hir::Ty stores spans of nested types in variant fields data and function argument types.

My main question is: does it make sense for rustc_public to have two set of types, like SpannedTy and Ty, in the future? How far rustc_public is going to go deep in the details of spans it reports?

[makai410]

I think if we could have a helper function that computes the span for a defid when requested then should be enough? such that we don't have to store the span info.

[bjorn3]

Function arguments do not have a DefId.

[makai410]

Ah good point. That said we're still able to get the span of a function's args through its MIR.

[hkalbasi]

Do variants and fields have DefId? Variants have DefId in rustc, but I think it is not reflected in rustc_public and it uses (AdtId, VariantIdx) as ID for variants. Fields do not have DefId in rustc either. I was wrong, fields have separate DefId but their are not available in rustc_public if I understand correctly.

Also it doesn't handle the inner parts of types. I guess we need a separate Ty and TyKind for this, but maybe there is a way to attach span to current Tys?

[makai410]

I guess we need a separate Ty and TyKind for this, but maybe there is a way to attach span to current Tys?

IIUC what you need is a syntactic type tree where every node has a span, which is essentially what HIR is. We do already expose some HIR information through rustc_public, so I think we could have more but for now we don't have any plan for that.

I don't think SpannedTy would be that useful and seemingly the wrong abstraction as it conflates syntax and semantics, but we could have something like Spanned<T> though.