2790

The issue alluded to in the previous 2789 is now fixed. I'm not happy
with my solution, though. I pollute Type_ordinal with type ingredients
in parse_type_tree and simply ignore such entries later on. I'd much
rather avoid the pollution in the first place, but I'm not sure how to
do that..

1 files changed, 29 insertions, 0 deletions

diff --git a/058shape_shifting_recipe.cc b/058shape_shifting_recipe.cc
index 35791147..26e0eaf6 100644
--- a/058shape_shifting_recipe.cc
+++ b/058shape_shifting_recipe.cc
@@ -660,6 +660,35 @@ container foo:_t [
 +mem: storing 0 in location 12
 +mem: storing 0 in location 13
 
+:(code)
+// this one needs a little more fine-grained control
+void test_shape_shifting_new_ingredient_does_not_pollute_global_namespace() {
+  Trace_file = "shape_shifting_new_ingredient_does_not_pollute_global_namespace";
+
+  // if you specialize a shape-shifting recipe that allocates a type-ingredient..
+  transform("def barz x:_elem [\n"
+            "  local-scope\n"
+            "  load-ingredients\n"
+            "  y:address:shared:number <- new _elem:type\n"
+            "]\n"
+            "def fooz [\n"
+            "  local-scope\n"
+            "  barz 34\n"
+            "]\n");
+  // ..and if you then try to load a new shape-shifting container with that
+  // type-ingredient
+  run("container foo:_elem [\n"
+      "  x:_elem\n"
+      "  y:number\n"
+      "]\n");
+  // then it should work as usual
+  reagent callsite("x:foo:point");
+  reagent element = element_type(callsite, 0);
+  CHECK_EQ(element.name, "x");
+  CHECK_EQ(element.type->name, "point");
+  CHECK(!element.type->right);
+}
+
 :(scenario shape_shifting_recipe_supports_compound_types)
 def main [
   1:address:shared:point <- new point:type