Added tests proving that the explicit context is evaluated using the global context of the partial containing the block (NOT the inline partial, which is where the explicit context is written).

js/test_cases/explicit_context_setting/README.md

@@ -17,7 +17,7 @@ Explicitly setting a context in a partial also works. The explicit context takes
 
 This works for both regular named partials and quoted partials.
 
-While normally parameters are injected 1 level above the current context, if both parameters and explicit are set, they are injected below the current context. So if the context tree was `1->2->3`, with just parameters you'd have `1->2->parameters->3` but with an explicit context you have `1->2->3->parameters->explicit`.
+While normally parameters are injected 1 level above the current context, if both parameters and explicit are set, they are injected below the current context. So if the context tree was `1->2->3`, with just parameters you'd have `1->2->parameters->3` but with an explicit context you have `parameters->explicit`.
 
 Helpers
 -------
@@ -31,6 +31,8 @@ Explicitly setting a context on an inline partial does not work, but it does not
 
 Explicitly setting a context on a block does work.
 
+The explicit context for inline partials is evaluated in the context for that template file containing the block, not the inline partial (so, whatever the context is when we invoke the partial containing the block).
+
 References
 ----------
 

js/test_cases/explicit_context_setting/explicit_evaluation_time.dust

@@ -0,0 +1,6 @@
+{#block}
+    {+pet_line}BLOCK: {contents}{~n}{/pet_line}
+{/block}
+{#inline_partial}
+    {<pet_line:message}INLINE PARTIAL: {contents}{~n}{/pet_line}
+{/inline_partial}

js/test_cases/explicit_context_setting/explicit_evaluation_time_split_default.dust

@@ -0,0 +1 @@
+{+pet_line}BLOCK: {contents}{~n}{/pet_line}

js/test_cases/explicit_context_setting/explicit_evaluation_time_split_override.dust

@@ -0,0 +1,4 @@
+{#block.message}
+    {>explicit_evaluation_time_split_default/}
+{/block.message}
+{<pet_line:message}INLINE PARTIAL: {contents}{~n}{/pet_line}

js/test_cases/explicit_context_setting/input1.json

@@ -28,5 +28,29 @@
       "pet": "cat"
     }
   },
-  "empty_array": []
+  "empty_array": [],
+  "block": {
+    "message": {
+      "contents": "Explicit contexts are evaluated in the context of the block."
+    }
+  },
+  "inline_partial": {
+    "message": {
+      "contents": "Explicit contexts are evaluated in the context of the inline partial."
+    }
+  },
+  "contents": "Explicit contexts are evaluated in the global context.",
+  "partial_context": {
+    "block": {
+      "message": {
+        "contents": "Explicit contexts are evaluated in the context of the block inside the partial context."
+      }
+    },
+    "inline_partial": {
+      "message": {
+        "contents": "Explicit contexts are evaluated in the context of the inline partial inside the partial context."
+      }
+    },
+    "contents": "Explicit contexts are evaluated in the global context inside the partial context."
+  }
 }

js/test_cases/explicit_context_setting/main.dust

@@ -269,3 +269,30 @@ Partial Overloaded Explicit with parameters{~n}
     {>other_friend:explicit friend="Dave" pet="rabbit"/}
 {/loop}
 
+{! Is an explicit context on an inline partial evaluated in the context of the block or the context of the inline partial? !}
+Explicit Evaluation Time Global{~n}
+==============================={~n}
+{>explicit_evaluation_time/}
+
+Explicit Evaluation Time Partial Context{~n}
+========================================{~n}
+{#partial_context}
+    {>explicit_evaluation_time/}
+{/partial_context}
+
+{! The previous test discovered that the inline partial's explicit context is evaluated based on the context when invoking the full-blown partial, HOWEVER, it shared the same partial context for both the block and the inline partial. To conclusively prove if the explicit context is evaluated on the inline partial and not the block, we need a different partial context for each one. !}
+Explicit Evaluation Time Split Partial Context Default{~n}
+======================================================{~n}
+{#partial_context}
+    {#block.message}
+        {>explicit_evaluation_time_split_default/}
+    {/block.message}
+{/partial_context}
+
+Explicit Evaluation Time Split Partial Context OVerride{~n}
+======================================================={~n}
+{#partial_context}
+    {#inline_partial}
+        {>explicit_evaluation_time_split_override/}
+    {/inline_partial}
+{/partial_context}

src/renderer/renderer.rs

@@ -314,6 +314,7 @@ impl<'a> DustRenderer<'a> {
             }
             DustTag::DTInlinePartial(_named_block) => {
                 // Inline partials are blank during rendering (they get injected into blocks)
+                // TODO: We will need to support explicit contexts for inline partials.
                 return Ok("".to_owned());
             }
             DustTag::DTBlock(named_block) => {
@@ -660,6 +661,7 @@ impl<'a> DustRenderer<'a> {
             Some(_) => Vec::with_capacity(3),
             None => breadcrumbs.clone(),
         };
+        // TODO: Can sections have parameters, and if so, what happens then? Currently when there is an injected context or an explicit context it gets inserted behind the current context, so 1->2->3 becomes 1->2->injected->3 or explicit->3. When there is a new context(4) with injected we're doing 1->2->3->injected->4. When there is an explicit context and a new context we're doing explicit->4. But what happens if there is a section with parameters and an explicit context, hitting all the categories? Would it be parameters->explicit->4? I would definitely have to change the parameters to this function since right now iteration variables and parameters are both sharing injected_context.
         injected_context.map(|ctx| {
             // Special case: when there is no explicit context or new
             // context element, the injected context gets inserted 1