Explain how nested generic args are represented#2809
Conversation
src/ty-module/generic-arguments.md
Outdated
|
|
||
| The [`ty::Generics`] type (returned by the [`generics_of`] query) contains the information of how the nested hierarchy | ||
| gets flattened down to a list, and lets you figure out which index in the `GenericArgs` list corresponds to which | ||
| generic (handling complications such as `Self` sometimes being a generic parameter). |
There was a problem hiding this comment.
what does “handling“ mean here? Will it normalize the Self type to a concrete Ty?
src/ty-module/generic-arguments.md
Outdated
| ``` | ||
|
|
||
| The construct `MyStruct::<u32>::func::<bool>` is represented by a tuple: a DefId pointing at `func`, and then a | ||
| `GenericArgs` list that "walks" from the outermost to innermost, left to right, of all containing generic arguments - in |
There was a problem hiding this comment.
“outermost” refers to the tcx.parent chain? and left-to-right refers to the order of the list?
There was a problem hiding this comment.
(I presume these are rhetorical questions, asking from the perspective of a reader, let me know if they're actual questions)
Hmm, my intent here was to be a bit vague and using simple imprecise "everyday" wording giving the general theme of how things work, rather than getting lost in the weeds of what specifically "outermost to innermost, left to right" means - especially as it quickly gets nontrivial, with things like the Self generic parameter, late-bound parameters, and the like. I was thinking the link to the ty::Generics would serve as a "ok, here's the weeds, if you want to know exactly how this works". Do you have a suggestion on how this should be worded? Perhaps just deleting this bit, to not imply specificity where there is none. (Pushed an update with an attempt at rewording)
There was a problem hiding this comment.
Actually, just spent a bit more time rewriting, hopefully that's clearer
There was a problem hiding this comment.
I am not aware of any authoritative reference for how this works, not even in the code. If you know one, please let me know. Otherwise it would be nice if we could make this section of the guide the reference.
There was a problem hiding this comment.
Unfortunately the current wording is my understanding from reading the code - if you'd prefer this PR's explanation is expanded, would you be okay with the current wording as is (something is better than nothing), then later expanding on it to be a more in-depth/authoritative reference later?
1f6f165 to
756df82
Compare
| Check out [`ty::Generics`] for exact specifics on how the flattening works. | ||
|
|
||
| [`ty::Generics`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Generics.html |
There was a problem hiding this comment.
I don't see any info about flattening here. Where did you get all this info from?
There was a problem hiding this comment.
Here, for example, is some details about how the flattening happens
src/ty-module/generic-arguments.md
Outdated
| ``` | ||
|
|
||
| The construct `MyStruct::<u32>::func::<bool>` is represented by a tuple: a DefId pointing at `func`, and then a | ||
| `GenericArgs` list that "walks" from the outermost to innermost, left to right, of all containing generic arguments - in |
There was a problem hiding this comment.
I am not aware of any authoritative reference for how this works, not even in the code. If you know one, please let me know. Otherwise it would be nice if we could make this section of the guide the reference.
| - Only early-bound generic parameters are included, [late-bound generics] are not. | ||
| - ... and more... | ||
|
|
||
| Check out [`ty::Generics`] for exact specifics on how the flattening works. |
There was a problem hiding this comment.
I think ideally there would be something better we could link but I'm not sure off the top of my head if such a place exists.
|
I'm going to merge this as I think it's good enough to be in the guide :) I think in general the overlap between the generic parameter definitions section and the ADTs section (this chapter) is unfortunate and should be some kind of unified whole somehow. Ah well :) thx all for the reviews |
fixes #2776
fyi @BoxyUwU (but I'll let the auto-review pick someone to not throw more on your plate)
r? rustc-dev-guide