- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
          Shrink SelectionError a lot
          #111029
        
          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
  
    Shrink SelectionError a lot
  
  #111029
              
            Conversation
| (rustbot has picked a reviewer for you, use r? to override) | 
| Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor | 
| @bors try @rust-timer queue | 
      
        
              This comment has been minimized.
        
        
      
    
  This comment has been minimized.
| ⌛ Trying commit b9b27667a60d6085e3f0d5f5ee765f1c9ccb3e65 with merge 15cc844067a9ed1563f8c11342cbbb1316a30f5c... | 
| ☀️ Try build successful - checks-actions | 
      
        
              This comment has been minimized.
        
        
      
    
  This comment has been minimized.
| Finished benchmarking commit (15cc844067a9ed1563f8c11342cbbb1316a30f5c): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment. 
 CyclesThis benchmark run did not return any relevant results for this metric. | 
| perf was neutral except for max RSS, which went down on diesel, makes sense. Given the small impact I can change this to the "light" version, just boxing away the large variant instead of this clever packing here. | 
| Left a couple of style comments. | 
b9b2766    to
    f3d7725      
    Compare
  
    | Changed it to the less invasive variant. | 
      
        
              This comment has been minimized.
        
        
      
    
  This comment has been minimized.
f3d7725    to
    dc86cbe      
    Compare
  
    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 pretty wrong, except it's not.
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.
expected_trait_ref in this fn is a misnomer. it comes from taking the self type from an obligation like fn(): Fn(i32) and turning it into the Fn trait that we know it does implement -- in this case, fn() implements Fn() from its signature. Then we equate fn(): Fn() ("expected") and fn(): Fn(i32) ("obligation"). But when we're reporting an error, the obligation trait ref is what we want to say was expected from the user's perspective.
we should probably rename the expected_trait_ref parameter in this fn.
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 renamed it to self_ty_trait_ref, not sure whether that's the best name.
`SelectionError` used to be 80 bytes (on 64 bit). That's quite big. Especially because the selection cache contained `Result<_, SelectionError>. The Ok type is only 32 bytes, so the 80 bytes significantly inflate the size of the cache. Most variants of the `SelectionError` seem to be hard errors, only `Unimplemented` shows up in practice (for cranelift-codegen, it occupies 23.4% of all cache entries). We can just box away the biggest variant, `OutputTypeParameterMismatch`, to get the size down to 16 bytes, well within the size of the Ok type inside the cache.
| 💔 Test failed - checks-actions | 
| @bors retry | 
| @bors treeclosed=50 | 
| ☀️ Test successful - checks-actions | 
| Finished benchmarking commit (f8d8ffa): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment. 
 CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 660.266s -> 659.801s (-0.07%) | 
SelectionErrorused to be 80 bytes (on 64 bit). That's quite big. Especially because the selection cache contained `Result<_, SelectionError>. The Ok type is only 32 bytes, so the 80 bytes significantly inflate the size of the cache.Most variants of the
SelectionErrorseem to be hard errors, onlyUnimplementedshows up in practice (for cranelift-codegen, it occupies 23.4% of all cache entries). We can just box away the biggest variant,OutputTypeParameterMismatch, to get the size down to 16 bytes, well within the size of the Ok type inside the cache.