-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Add ConstParamTy
trait
#108161
Add ConstParamTy
trait
#108161
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
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.
Thanks this is great :D
- Could you move the tests to
tests/ui/const-generics/adt_const_params/
apparently this directory doesn't yet exist so you'll have to make it 😅 - There's a typo in the current added test
const_patam_ty_...
rather thanconst_param_ty_...
- I think we ought to have test that each of the special cases in
visit_implementations_of_const_param_ty
actually has an impl present 🤔 And also tests that when the bounds dont hold on those special cases we correctly get an error. And also that the builtin types that dont have a special case, don't implementConstParamTy
(i.e.FnDef
/Closure
/FnPtr
/&mut
/*mut
/*const
note that this is a non exhaustive list apparently we have a lot of nonStructuralEq
builtin types x3) - A test that when you have
struct Foo(ImplementsConstParamTy)
and you try to doimpl ConstParamTy for Foo
it fails because noStructuralEq
would also be good :D
|
||
&ty::Adt(adt, substs) => (adt, substs), | ||
|
||
_ => return Err(ConstParamTyImplementationError::NotAnAdtOrBuiltinAllowed), |
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.
Looking through TyKind
I think we need more special cases here 😭, some of them are going to need to evaluate obligations to see if its allowed or not though you can probably use ObligationCtxt
for that in this fn 🤔
ty::Str
should be usable and probably require[u8]: ConstParamTy
to act as ifStr
wasstruct Str([u8])
.- Should add an impl for
impl ConstParamTy for str
in core
- Should add an impl for
ty::Array
should be usable and requireT: ConstParamTy
- Should add an impl for
impl<T: ConstParamTy, const N: usize> ConstParamTy for [T; N]
in core
- Should add an impl for
ty::Slice
should be usable and requireT: ConstParamTy
- Should add an impl for
impl<T: ConstParamTy> ConstParamTy for [T]
in core
- Should add an impl for
ty::Ref
when itsMutability::Not
and requireT: ConstParamTy
- Should add an impl for
impl<T: ConstParamTy> ConstParamTy for &'_ T
in core
- Should add an impl for
ty::Tuple
should be usable and requireT: ConstParamTy
for all the elements- Should add an impl in core via a macro? How does std do its current impls for tuples xd
I think eventually we want some logic around ty::FnDef
and ty::Closure
but that is likely going to require builtin impl candidates, and without feature(generic_const_parameter_types)
you can't even write an adt_const_param
that has one of those types. Could you add a FIXME(generic_const_parameter_types)
here to make ty::FnDef
/ty::Closure
work?
edit: Oh a test that [NotConstParamTy; 0]
does NOT implement ConstParamTy
from the blanket impl in core would be phenomenal
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.
generic_const_parameter_types
Is it okay that this feature does not exist?
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.
yea its not yet implemented lol but that will be what i call the feature gate when its done 😅
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.
this match needs to actually evaluate obligations checking the things i said should be required so that you cant even write an impl like impl<T> ConstParamTy for &T {}
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.
Wouldn't it duplicate the bounds we have anyway in the core
? I don't really see the reason why we need to also check them here (type_allowed_to_implement_copy
doesn't, as an example).
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.
yes it would duplicate the bounds we have in core in the same way that if you have a struct Foo<T>(T);
the impl needs to write T: ConstParamTy
and rustc needs to check that T: ConstParamTy
holds. also dont really care if type_allowed_to_implement_copy
is a bit buggy and relies on std not doing impls wrong because i'd rather the compiler just not allow you to get this wrong.
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.
My point is: we already depend on std being correct in a myriad of ways, for all intents and purposes from the perspective of the compiler std
must be correct.
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.
I don't see why we should rely on std being correct with regards to this, its easily checkable and no where is it clear that implementing Copy
or ConstParamTy
is actually unsafe inside of std
This comment has been minimized.
This comment has been minimized.
ceb93df
to
4d4d661
Compare
@BoxyUwU I think I did almost all the things you've asked for. I did not implement the trait for tuples, because it kind-of requires refactoring of If you don't have any objections I would propose to merge this as-is and leave the following tasks as follow-ups (in order in which they should probably be done):
|
☔ The latest upstream changes (presumably #108919) made this pull request unmergeable. Please resolve the merge conflicts. |
Discussed in T-compiler triage meeting today. @BoxyUwU says they'll likely r+ as-is after its rebased to address the merge conflicts. @rustbot label: -S-waiting-on-review +S-waiting-on-author |
(how did this work before??)
b0dd920
to
26417a8
Compare
This comment has been minimized.
This comment has been minimized.
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.
I have not looked at the compiler changes but r=me on the new normalization in compiletest
This comment has been minimized.
This comment has been minimized.
@rustbot ready |
//[min]~^^^^^^^^^^^^ ERROR `[u8; { | ||
|
||
// N.B. it is important that the comment above is not inside the array length, | ||
// otherwise it may check for itself, instead of the actual error |
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.
this is hilarious actually
nice find :)
(`StructuralEq` is shallow for some reason...)
@bors r+ sorry for this PR taking so long D: |
Rollup of 7 pull requests Successful merges: - rust-lang#105076 (Refactor core::char::EscapeDefault and co. structures) - rust-lang#108161 (Add `ConstParamTy` trait) - rust-lang#108668 (Stabilize debugger_visualizer) - rust-lang#110512 (Fix elaboration with associated type bounds) - rust-lang#110895 (Remove `all` in target_thread_local cfg) - rust-lang#110955 (uplift `clippy::clone_double_ref` as `suspicious_double_ref_op`) - rust-lang#111048 (Mark`feature(return_position_impl_trait_in_trait)` and`feature(async_fn_in_trait)` as not incomplete) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
/// } | ||
/// ``` | ||
#[unstable(feature = "internal_impls_macro", issue = "none")] | ||
macro marker_impls { |
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.
fwiw this kinda broke things with r-a because it's still really bad at handling textual macro scopes in regards to shadowing 🙃 rust-lang/rust-analyzer#14862
We'll try fixing this on our side in a timely manner obviously, but still raising this in case we can't for architectural reasons.
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.
For future reference: this was changed in #111810
This is a bit sketch, but idk.
r? @BoxyUwU
Yet to be done:
Figure out if it's okay to implement(it should be okay, but maybe not in this PR...)StructuralEq
for primitives / possibly remove their special casingFuture work:
const
generic type is allowedmarker.rs
into multiple modules for each "theme" of markers