Merge pull request #5203 from roc-lang/virtual-dom-annotations

Fix a few bugs Virtual-DOM cropped up

crates/compiler/derive_key/src/decoding.rs

@@ -96,7 +96,8 @@ impl FlatDecodable {
                 Self::from_var(subs, range.default_compilation_variable())
             }
             //
-            Content::RecursionVar { .. } => Err(Underivable),
+            Content::RecursionVar { structure, .. } => Self::from_var(subs, structure),
+            //
             Content::Error => Err(Underivable),
             Content::FlexVar(_)
             | Content::RigidVar(_)

crates/compiler/derive_key/src/encoding.rs

@@ -130,7 +130,8 @@ impl FlatEncodable {
                 Self::from_var(subs, range.default_compilation_variable())
             }
             //
-            Content::RecursionVar { .. } => Err(Underivable),
+            Content::RecursionVar { structure, .. } => Self::from_var(subs, structure),
+            //
             Content::Error => Err(Underivable),
             Content::FlexVar(_)
             | Content::RigidVar(_)

crates/compiler/mono/src/ir.rs

@@ -5792,12 +5792,17 @@ fn late_resolve_ability_specialization<'a>(
             solved,
             unspecialized,
             recursion_var: _,
-            ambient_function: _,
+            ambient_function,
         } = env.subs.get_lambda_set(*lambda_set);
 
         debug_assert!(unspecialized.is_empty());
         let mut iter_lambda_set = solved.iter_all();
-        debug_assert_eq!(iter_lambda_set.len(), 1);
+        debug_assert_eq!(
+            iter_lambda_set.len(),
+            1,
+            "{:?}",
+            (env.subs.dbg(*lambda_set), env.subs.dbg(ambient_function))
+        );
         let spec_symbol_index = iter_lambda_set.next().unwrap().0;
         env.subs[spec_symbol_index]
     } else {

crates/compiler/solve/src/solve.rs

@@ -3921,7 +3921,23 @@ fn adjust_rank_content(
         Alias(_, args, real_var, _) => {
             let mut rank = Rank::toplevel();
 
-            for var_index in args.all_variables() {
+            // Avoid visiting lambda set variables stored in the type variables of the alias
+            // independently.
+            //
+            // Why? Lambda set variables on the alias are not truly type arguments to the alias,
+            // and instead are links to the lambda sets that appear in functions under the real
+            // type of the alias. If their ranks are adjusted independently, we end up looking at
+            // function types "inside-out" - when the whole point of rank-adjustment is to look
+            // from the outside-in to determine at what rank a type lies!
+            //
+            // So, just wait to adjust their ranks until we visit the function types that contain
+            // them. If they should be generalized (or pulled to a lower rank) that will happen
+            // then; otherwise, we risk generalizing a lambda set too early, when its enclosing
+            // function type should not be.
+            let adjustable_variables =
+                (args.type_variables().into_iter()).chain(args.infer_ext_in_output_variables());
+
+            for var_index in adjustable_variables {
                 let var = subs[var_index];
                 rank = rank.max(adjust_rank(subs, young_mark, visit_mark, group_rank, var));
             }

crates/compiler/unify/src/unify.rs

@@ -1820,15 +1820,6 @@ fn unify_unspecialized_lambdas<M: MetaCollector>(
                             let _dropped = uls_right.next().unwrap();
                             let kept = uls_left.next().unwrap();
                             merged_uls.push(*kept);
-
-                            debug_assert!(uls_right
-                                .peek()
-                                .map(|r| env.subs.equivalent_without_compacting(var_l, r.0))
-                                .unwrap_or(true));
-                            debug_assert!(uls_left
-                                .peek()
-                                .map(|l| env.subs.equivalent_without_compacting(l.0, var_r))
-                                .unwrap_or(true));
                         } else {
                             // Even if these two variables unify, since they are not equivalent,
                             // they correspond to different specializations! As such we must not