language-servers/roc
1
0
Fork 0
mirror of https://github.com/roc-lang/roc.git synced 2025-07-24 15:03:46 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6

Remove dead code

Browse source
This commit is contained in:
Ayaz Hafiz 2022-07-14 16:05:27 -04:00
parent 6611cce22c
commit 51fd7711e7
No known key found for this signature in database
GPG key ID: 0E2A37416A25EF58
1 changed files with 28 additions and 51 deletions
Download patch file Download diff file Expand all files Collapse all files

79
crates/compiler/unify/src/unify.rs
View file

@ -1336,57 +1336,6 @@ fn unify_lambda_set_help<M: MetaCollector>(
merge(subs, ctx, new_lambda_set)
}
/// Ensures that a non-recursive tag union, when unified with a recursion var to become a recursive
/// tag union, properly contains a recursion variable that recurses on itself.
//
// When might this not be the case? For example, in the code
//
// Indirect : [Indirect ConsList]
//
// ConsList : [Nil, Cons Indirect]
//
// l : ConsList
// l = Cons (Indirect (Cons (Indirect Nil)))
// # ^^^^^^^^^^^^^^^~~~~~~~~~~~~~~~~~~~~~^ region-a
// # ~~~~~~~~~~~~~~~~~~~~~ region-b
// l
//
// Suppose `ConsList` has the expanded type `[Nil, Cons [Indirect <rec>]] as <rec>`.
// After unifying the tag application annotated "region-b" with the recursion variable `<rec>`,
// the tentative total-type of the application annotated "region-a" would be
// `<v> = [Nil, Cons [Indirect <v>]] as <rec>`. That is, the type of the recursive tag union
// would be inlined at the site "v", rather than passing through the correct recursion variable
// "rec" first.
//
// This is not incorrect from a type perspective, but causes problems later on for e.g. layout
// determination, which expects recursion variables to be placed correctly. Attempting to detect
// this during layout generation does not work so well because it may be that there *are* recursive
// tag unions that should be inlined, and not pass through recursion variables. So instead, try to
// resolve these cases here.
//
// See tests labeled "issue_2810" for more examples.
fn fix_tag_union_recursion_variable<M: MetaCollector>(
subs: &mut Subs,
ctx: &Context,
tag_union_promoted_to_recursive: Variable,
recursion_var: &Content,
) -> Outcome<M> {
debug_assert!(matches!(
subs.get_content_without_compacting(tag_union_promoted_to_recursive),
Structure(FlatType::RecursiveTagUnion(..))
));
let has_recursing_recursive_variable = subs
.occurs_including_recursion_vars(tag_union_promoted_to_recursive)
.is_err();
if !has_recursing_recursive_variable {
merge(subs, ctx, *recursion_var)
} else {
Outcome::default()
}
}
fn unify_record<M: MetaCollector>(
subs: &mut Subs,
pool: &mut Pool,
@ -2047,6 +1996,34 @@ fn unify_shared_tags_new<M: MetaCollector>(
if outcome.mismatches.is_empty() {
// If one of the variables is a recursion var, keep that one, so that we avoid inlining
// a recursive tag union type content where we should have a recursion var instead.
//
// When might this happen? For example, in the code
//
// Indirect : [Indirect ConsList]
//
// ConsList : [Nil, Cons Indirect]
//
// l : ConsList
// l = Cons (Indirect (Cons (Indirect Nil)))
// # ^^^^^^^^^^^^^^^~~~~~~~~~~~~~~~~~~~~~^ region-a
// # ~~~~~~~~~~~~~~~~~~~~~ region-b
// l
//
// Suppose `ConsList` has the expanded type `[Nil, Cons [Indirect <rec>]] as <rec>`.
// After unifying the tag application annotated "region-b" with the recursion variable `<rec>`,
// we might have that e.g. `actual` is `<rec>` and `expected` is `[Cons (Indirect ...)]`.
//
// Now, we need to be careful to set the type we choose to represent the merged type
// here to be `<rec>`, not the tag union content of `expected`! Otherwise, we will
// have lost a recursion variable in the recursive tag union.
//
// This would not be incorrect from a type perspective, but causes problems later on for e.g.
// layout generation, which expects recursion variables to be placed correctly. Attempting to detect
// this during layout generation does not work so well because it may be that there *are* recursive
// tag unions that should be inlined, and not pass through recursion variables. So instead, resolve
// these cases here.
//
// See tests labeled "issue_2810" for more examples.
let merged_var = match (
(actual, subs.get_content_unchecked(actual)),
(expected, subs.get_content_unchecked(expected)),