-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Misc cleanups of generic_arg_infer
related HIR logic
#142678
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
generic_arg_infer
related logicgeneric_arg_infer
related HIR logic
/// ambiguous context the parameter is instantiated with an uninhabited type making the | ||
/// [`ConstArgKind::Infer`] variant unusable and [`GenericArg::Infer`] is used instead. | ||
/// For an explanation of the `Unambig` generic parameter see the dev-guide: | ||
/// https://rustc-dev-guide.rust-lang.org/hir/ambig-unambig-ty-and-consts.html |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All these links need to be wrapped in <
and >
, otherwise they don't get linkified.
E.g.,
/// https://rustc-dev-guide.rust-lang.org/hir/ambig-unambig-ty-and-consts.html | |
/// <https://rustc-dev-guide.rust-lang.org/hir/ambig-unambig-ty-and-consts.html> |
(Not sure if CI will catch this but it prolly will (lint: rustdoc::bare_urls
))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah...
The job Click to see the possible cause of the failure (guessed by this bot)
|
// SAFETY: `repr(u8)` is required so that `TyKind<()>` and `TyKind<!>` are layout compatible | ||
#[repr(u8, C)] | ||
#[derive(Debug, Clone, Copy, HashStable_Generic)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why these new derives?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not new I just moved them below all the comments
/// unambiguously a const or ambiguous as to whether it is a type or a const. When in an | ||
/// ambiguous context the parameter is instantiated with an uninhabited type making the | ||
/// [`ConstArgKind::Infer`] variant unusable and [`GenericArg::Infer`] is used instead. | ||
/// For an explanation of the `Unambig` generic parameter see the dev-guide: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a lot of links to the same guide section. Are they all necessary? Maybe just the ones on types, and cut the ones on methods? Feels like the balance between "thoroughness" and "don't repeat yourself" is off?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I went a bit heavy here on just linking it from everywhere that people might wind up having questions. I don't have a good sense for if people would go looking at the API docs on ConstArg
/Ty
if they find things confusing in the methods.
Happy to just only link to the dev-guide docs from the types themselves instead of the methods though if you think that would make more sense and still be useful for people
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, type-level or trait-level linkage introducing the concepts the type or trait's associated items reference makes more sense to me.
r? @nnethercote