- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
          Add ConstParamTy trait
          #108161
        
          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
              
            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_tyactually 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/*constnote that this is a non exhaustive list apparently we have a lot of nonStructuralEqbuiltin types x3)
-  A test that when you have struct Foo(ImplementsConstParamTy)and you try to doimpl ConstParamTy for Fooit fails because noStructuralEqwould also be good :D
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::Strshould be usable and probably require- [u8]: ConstParamTyto act as if- Strwas- struct Str([u8]).- Should add an impl for impl ConstParamTy for strin core
 
- Should add an impl for 
- ty::Arrayshould be usable and require- T: ConstParamTy- Should add an impl for impl<T: ConstParamTy, const N: usize> ConstParamTy for [T; N]in core
 
- Should add an impl for 
- ty::Sliceshould be usable and require- T: ConstParamTy- Should add an impl for impl<T: ConstParamTy> ConstParamTy for [T]in core
 
- Should add an impl for 
- ty::Refwhen its- Mutability::Notand require- T: ConstParamTy- Should add an impl for impl<T: ConstParamTy> ConstParamTy for &'_ Tin core
 
- Should add an impl for 
- ty::Tupleshould be usable and require- T: ConstParamTyfor 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...)StructuralEqfor primitives / possibly remove their special casingFuture work:
constgeneric type is allowedmarker.rsinto multiple modules for each "theme" of markers