Document current limitation of type aliases on enums

[bstrie]

Question: is the intent of the reference to document how the language currently is, or how it should be? Because the behavior documented in this PR is something that I would like to be changed in the future (rust-lang/rust#83248), but in the meantime it might be useful to readers to better understand the limitations of type aliases as they are currently implemented.

[petrochenkov]

This is not a separate rule though, just an example of type-relative resolution not being supported in imports due to compiler staging.

[bstrie]

@petrochenkov It would still be useful to mention that rule somewhere on this page. Is there a better way to word it, or some canonical part of the reference to link to?

[Havvy]

I looked around in different places for the general rule, but I don't see it documented anywhere. I'm also not sure how to formulate the general rule, so I don't know where it would go either.

[ehuss]

I think this boils down to documenting uniform paths (#487). I thought there was something already in the reference about multi-segment paths and the requirements of the non-terminal segments, but I can't find anything.

I think this would end up being part of (possibly significant) changes to the "Paths" chapter, the overhaul of the "Use declarations" chapter, and writing the "Resolution" chapter which could help clarify how paths are handled.

I have been slowly making progress in the background on name resolution, which ties into all of this.

[bstrie]

Shall I close this in favor of your future additions, then?

[Havvy]

FWIW, having it now would be better than waiting for the indeterminate future since it can always be removed later. But I don't know @ehuss's progress, so I'll .await their answer to the question.

[bstrie]

I'll close this for now; I've left a comment on #487 to help remember to document this specific case in the future.