language-servers/roc
1
0
Fork 0
mirror of https://github.com/roc-lang/roc.git synced 2025-09-27 22:09:09 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6

Distinguish between pending and resolved ability stores

Browse source 
Now that we have unspecialized lambda sets, we need to properly copy
their specialization variables when a module imports another modules'
ability store. I think it will be easier to ensure the correctness if
we distinguish between a "pending" ability store (which may contain
imports whose variables have not been added to subs yet) and "resolved"
abilities stores, which are what we care about for solve and later on.

There is a cost to this since `PendingAbilitiesStore#resolve` destroys
and collects all of the ability member data, rather than in-place
mutating as we did before. However, the resulting `AbilitiesStore` is
now much smaller, so the memory footprint will be better, and also
every field besides `ability_members` will be moved rather than copied.
This commit is contained in:
Ayaz Hafiz 2022-06-09 12:52:40 -04:00
parent a57dd820a1
commit aa9b70a7c8
No known key found for this signature in database
GPG key ID: 0E2A37416A25EF58
8 changed files with 228 additions and 139 deletions
Download patch file Download diff file Expand all files Collapse all files

4
compiler/solve/src/solve.rs
View file

@ -1549,9 +1549,7 @@ fn check_ability_specialization(
// inferred type for the specialization actually aligns with the expected
// implementation.
if let Some((ability_member, root_data)) = abilities_store.root_name_and_def(symbol) {
let root_signature_var = root_data.signature_var().unwrap_or_else(|| {
internal_error!("Signature var not resolved for {:?}", ability_member)
});
let root_signature_var = root_data.signature_var();
let parent_ability = root_data.parent_ability;
// Check if they unify - if they don't, then the claimed specialization isn't really one,