- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
Add auto traits and clone trait migrations for RFC2229 #84730
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
Conversation
      
        
              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.
mostly nits
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.
nit: maybe its better to do this with a helper like (just to reduce some degree of duplication):
- Check need_2229_migrations_for_trait(var_hir_id, trait)- Checks for the specific var_hir meets trait bound
- Loops over all captures and see if that trait bound is met
 
and then this function can just do
if need_2229_migrations..(var_hir_id, tcx.lang_items().clone_trait()) {
       auto_trait_reasons.insert("`Clone`");
}
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.
A helper function does seem like it would be good here.
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 can just be need need_auto_trait_migrations || need_drop_migrations
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 still think it's simple to just use need_migrations. Since we do need to handle drop and auto_trait migration differently
        
          
                src/test/ui/closures/2229_closure_analysis/migrations/auto_traits.rs
              
                Outdated
          
            Show resolved
            Hide 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.
Do we have a test that causes some variable to be captured for multiple reasons -- e.g., because of Send but also because of destructors?
Combine all 2229 migrations under one flag name
      
        
              This comment has been minimized.
        
        
      
    
  This comment has been minimized.
      
        
              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.
This looks about ready to land! One nit.
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.
A helper function does seem like it would be good here.
| @bors r+ | 
| 📌 Commit 564b4de has been approved by  | 
| ☀️ Test successful - checks-actions | 
| Performance triage indicates that this PR introduced a 1.4% regression when fully compiling  I don't think any performance hit was expected. However, it also seems like this may be just noise. | 
| RangeTo, sym::RangeTo, range_to_struct, Target::Struct; | ||
| Send, sym::send, send_trait, Target::Trait; | ||
| UnwindSafe, sym::unwind_safe, unwind_safe_trait, Target::Trait; | ||
| RefUnwindSafe, sym::ref_unwind_safe, ref_unwind_safe_trait, Target::Trait; | 
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've just seen in #86603 that Send is made a lang item again.
I don't see why this PR needs to add new lang items, all of these could be diagnostic items instead.
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 true, I forgot that diagnostic items were a thing.
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.
@petrochenkov Thanks for pointing this out, I'll try to have a fix done in the next few days.
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.
@petrochenkov The fix is up for review #86726
…-rfc2229-migration, r=nikomatsakis Use diagnostic items instead of lang items for rfc2229 migrations This PR removes the `Send`, `UnwindSafe` and `RefUnwindSafe` lang items introduced in rust-lang#84730, and uses diagnostic items instead to check for `Send`, `UnwindSafe` and `RefUnwindSafe` traits for RFC2229 migrations. r? `@nikomatsakis`
…-rfc2229-migration, r=nikomatsakis Use diagnostic items instead of lang items for rfc2229 migrations This PR removes the `Send`, `UnwindSafe` and `RefUnwindSafe` lang items introduced in rust-lang#84730, and uses diagnostic items instead to check for `Send`, `UnwindSafe` and `RefUnwindSafe` traits for RFC2229 migrations. r? ``@nikomatsakis``
…-rfc2229-migration, r=nikomatsakis Use diagnostic items instead of lang items for rfc2229 migrations This PR removes the `Send`, `UnwindSafe` and `RefUnwindSafe` lang items introduced in rust-lang#84730, and uses diagnostic items instead to check for `Send`, `UnwindSafe` and `RefUnwindSafe` traits for RFC2229 migrations. r? ```@nikomatsakis```
This PR
disjoint_capture_drop_reordertodisjoint_capture_migrationCloses rust-lang/project-rfc-2229#29
Closes rust-lang/project-rfc-2229#28
r? @nikomatsakis