- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
Deduplicate bounds on associated types when deriving #92793
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
Deduplicate bounds on associated types when deriving #92793
Conversation
A remnant from the before times...
"Simple" uses have no qualified self type or generic parameters. They're just a path (e.g. `T::Item`).
| r? @wesleywiser (rust-highfive has picked a reviewer for you, use r? to override) | 
| I didn't see a test for derived impls on declarations referencing associated types. Am I missing something obvious? AFAIK, there's no way to test that deduplication is actually occurring in a UI test, but we should have something to ensure that I haven't broken anything. | 
      
        
              This comment has been minimized.
        
        
      
    
  This comment has been minimized.
2580076    to
    fd589e6      
    Compare
  
    | 
 I found  Since you noticed the issue via rustdoc, perhaps a rustdoc test would be able to show the deduplication is occurring? | 
| ☔ The latest upstream changes (presumably #91359) made this pull request unmergeable. Please resolve the merge conflicts. | 
| Ping from Triage: | 
| Closing this as inactive | 
poloniususes a trait with a few associated types to define which newtyped indexes represent CFG points, loans, etc.rustcmakes no effort to deduplicate bounds when deriving common traits on structures whose fields mention associated types, resulting in very large, redundantwhereclauses like this one. I find this mildly annoying when reading documentation.This PR adds deduplication of simple paths (no generic arguments or qualified self types) to the
derivemachinery. As a result, the derived impl I linked above has only a single bound for each associated type, as one might expect.