Refactor setup_associated_types #1105
Comments
Merged
philberty
added a commit
that referenced
this issue
Apr 28, 2022
From PR #1086 I introduced a new setup_associated_types2 interface which is used to ensure we handle the complex associated types in libcore slices but this interface was inconsistant as well as the get_projected_type. This path refactors the code base to get rid of the old setup_associated_types interface in favour of this new one. It also removes the get_projected_type interface which was not going to work either. Fixes #1105
bors bot
added a commit
that referenced
this issue
Apr 28, 2022
1190: Fix ICE in reachability class and refactor associated types code r=philberty a=philberty There are several fixes going on to solve these issues which overlap with one another so it seemed best to pack them within the same PR. The main issue for #1128 was that we did not resolve a trait when it was unused leading to us hitting the ICE in the privacy pass. Since the type check context was empty for the trait since it was not resolved. To fix this we needed to refactor the trait resolver to resolve the trait as part of iterating the crate. This resulted in some regressions in the testsuite so this is why we need the the other commits. Which required us to finally perform the refactor specified in #1105 to fix these. Fixes #1105 #1128 #1132 1192: Add an assertion to avoid peeking when the stack is empty r=philberty a=philberty This will ensure we get a proper ICE instead of memory corruption/segv. Addresses #1130 1193: Remove unused parameter caller from generating Call expressions r=philberty a=philberty Within const context the fncontext maybe empty which in turn results in a segv for generating const calls which will be evaluated by the const-expr code anyway. Addresses #1130 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think the name might be a little unclear. Can we overload the previous
setup_associated_typesor maybe give it a name reflecting the fact that it performs a different operation?Originally posted by @CohenArthur in #1086 (comment)
The text was updated successfully, but these errors were encountered: