- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
          -Znext-solver allow ExprKind::Call for not-yet defined opaques
          #145993
        
          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
| 
 | 
-Znext-solver allow ExprKind::Call on not-yet defined opaques-Znext-solver allow ExprKind::Call for not-yet defined opaques
      
      
        
              This comment has been minimized.
        
        
      
    
  This comment has been minimized.
| ☔ The latest upstream changes (presumably #146023) made this pull request unmergeable. Please resolve the merge conflicts. | 
9ccb5e9    to
    279018c      
    Compare
  
    
      
        
              This comment has been minimized.
        
        
      
    
  This comment has been minimized.
279018c    to
    102a7d6      
    Compare
  
    
      
        
              This comment has been minimized.
        
        
      
    
  This comment has been minimized.
219519c    to
    c9f782a      
    Compare
  
    dc1b010    to
    efde093      
    Compare
  
    | @bors try @rust-timer queue | 
      
        
              This comment has been minimized.
        
        
      
    
  This comment has been minimized.
`-Znext-solver` allow `ExprKind::Call` for not-yet defined opaques
      
        
              This comment has been minimized.
        
        
      
    
  This comment has been minimized.
| Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor | 
      
        
              This comment has been minimized.
        
        
      
    
  This comment has been minimized.
dcf560a    to
    c8a3348      
    Compare
  
    | return None; | ||
| } | ||
|  | ||
| ty::Infer(ty::TyVar(vid)) => { | 
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.
feels subtle to me that we are specifically checking for TyVar instead of just all ty::Infer? How does the rest of the code handle int/float vars
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.
can never impl Fn and Deref, so 🤷 we generally accept int/float infer vars, e.g. structurally_resolve_type also does so
| // To do so we don't eagerly bail if the current type is the hidden type of an | ||
| // opaque type and instead return `None` in `fn overloaded_deref_ty` if the | ||
| // opaque does not have a `Deref` item-bound. | ||
| if let &ty::Infer(ty::TyVar(vid)) = self.state.cur_ty.kind() | 
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.
similar here, I realise we previously only checked is_ty_var, but how does the rest of this codepath handle int/float vars
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.
they don't implement Deref so they are the final self type and users of autoderef have to handle them if necessary
| imm_tr, | ||
| base_ty, | ||
| opt_rhs_ty, | ||
| TreatNotYetDefinedOpaques::AsInfer, | 
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 guess its the same reasoning here?
| mut_tr, | ||
| base_ty, | ||
| opt_rhs_ty, | ||
| TreatNotYetDefinedOpaques::AsInfer, | 
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 guess its the same reasoning here?
c8a3348    to
    173233e      
    Compare
  
    173233e    to
    9913c47      
    Compare
  
    | @bors r=BoxyUwU :3 | 
| ☀️ Test successful - checks-actions | 
| What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 32e3d9f (parent) -> 4cd91ef (this PR) Test differencesShow 45 test diffsStage 1
 Stage 2
 Additionally, 21 doctest diffs were found. These are ignored, as they are noisy. Job group index 
 Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 4cd91ef8223ef54111d21aa9e9e71b3b26477dd3 --output-dir test-dashboardAnd then open  Job duration changes
 How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance | 
| Finished benchmarking commit (4cd91ef): comparison URL. Overall result: ❌✅ regressions and improvements - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy. 
 Max RSS (memory usage)Results (secondary 3.8%)A less reliable metric. May be of interest, but not used to determine the overall result above. 
 CyclesResults (primary -2.1%, secondary -2.6%)A less reliable metric. May be of interest, but not used to determine the overall result above. 
 Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 471.73s -> 473.718s (0.42%) | 
support opaque types in method selection See my notes in https://hackmd.io/4ILASx3mQ3u_gW9r1JyqCw. This PR builds on #145993 and allows not-yet defined opaque types as self types in the `method_autoderef_chain`. E.g. for `Box<impl Deref<impl Foo>>` this results in the autoderef chain `Box<impl Deref> -> ?deref_hidden_ty -> ?foo_hidden_ty`. Method selection stays ambiguous if the final autoderef step is still an infer var unless that var is an opaque. TODO: treating opaques as rigid jank. r? `@BoxyUwU`
Based on #146329. Revival of #140496. See the comment on
OpaqueTypesJank. I've used the following document while working on this https://hackmd.io/Js61f8PRTcyaiyqS-fH9iQ.Fixes rust-lang/trait-system-refactor-initiative#181. It does introduce one subtle footgun we may want to handle before stabilization, opened rust-lang/trait-system-refactor-initiative#230 for that. Also cc rust-lang/trait-system-refactor-initiative#231 for deref and index operations
r? @BoxyUwU