Followup from [this discussion](#150 (comment))

The idea here is:

1. Explicit repeat creation in tests will improve test clarity

2. Introduce a clear way to make similar changes in JavaRosa as they come up

3. Detect missing repeats (with a still naive approach[^1], albeit now recursive) and **log with a stack trace** so explicit calls can be introduced (conditionally, with parameterization like many other cases where we make adjustments to the JavaRosa direct port)

4. Add a new proposed `Scenario` method which…

  - Makes clear where explicit repeat creation calls are added, in a way that can be traced directly in test source, whenever convenient

  - Assumes the call occurs in such a sub-suite parameterizing whether to explicitly add repeats as detected; adds repeats as explicitly specified in the true condition, suppresses logging in the false condition

This approach already detected one test which would have passed if adding repeats had been explicit. The test is updated here to demonstrate that.

Notice that the test’s **PORTING NOTES** have also been removed. This is because the notes were wrong! This is an excellent example of how misleading it is that tests fail for lack of this implicit behavior! The actual test logic is not substantially noisier or more complex as a result. This feels like a clear win to me.

[^1]: Keeping this naive seems fine for the limited scope of usage. The reference expressions which reach this point are limited to `Scenario.answer` calls with an explicit reference. If we’re using references of arbitrary complexity in those calls, I think we’ve got much bigger problems than this functionality being so narrowly scoped.

… resolution, dependency identification

Function call analysis is generalized and streamlined, and used to help various other aspects of path-related static analysis.

Path resolution:

- Accounts for arbitrary self/parent steps (of any number, at any depth in a path)
- Resolves relative paths to arbitray Absolute and FilterExpr contexts
- Resolves current() calls to either:
  - The step in a [partial] path expression where called in a predicate on that step
  - The context (typically parent) of an expression’s definition

Dependency identification:

- Benefits from all of the above path resolution improvements
- Accurately contextualizes dependencies referencing current() (which will improve reactivity for a variety of form logic cases)
- Accurately identifies and contextualizes arbitrary sub-expressions in predicates (which will improve reactivity for form logic cases with more complex logic)

…orm definition (typically body)

Note that this breaks up parsing of…

- `<item><label ref>`, where arbitrary references may be contextualized to their parent nodeset
- `<itemset><label ref>`, where a relative expression is intentionally kept unresolved (ensuring that evaluation of dynamic itemsets update correctly when the itemset nodeset expression is a form state reference (i.e. repeat-based itemsets)

…text

This ensures that:

- if relative, the nodeset expression itself is contextualized correctly
- in any case, that any dependencies identified in the dynamic item expression are resolved to the correct context

…ogic

This wil improve a variety of edge cases, and will be most visible in the correct tracking of:

- `current()` references in expressions
- any references found in expressions’ predicates

Test is fixed by stripping predicates in dependency analysis

This **will change** when we implement support for `jr:count` and `jr:noAddRemove`. The intent of implementing it now is to ensure, in subsequent commits, that adding explicit repeat creation does not cause false positives in new test passage

…peats will not be allowed

Technically this is a bit of a fib! The engine/client API will still permit repeat creation calls. But its passing now will ensure we continue to keep it passing when we implement the pertinent functionality

As discussed in review, it’s highly unlikely this is actually needed anymore!

Brief backstory context in case we ever have reason to doubt this:

0. The WHO VA form, which I’ve used as a frame of reference for many things, uses two references to `null` that don’t resolve to anything. The inferred intent is to treat `null` as a keyword, just as it would be in languages with the Billion Dollar Mistake.
1. In early prototyping (pre Web Forms project), the WHO VA form’s references to `null` produced errors where there was assertion logic checking that expected dependencies were found.
2. Early Web Forms work produced the same, for a time at least producing errors in the console. This produced a lot of distracting noise that made it harder to identify actual implementation errors in dependency resolution.
3. Subsequent improvements to dependency resolution have been successful enough that we’ve even eschewed logging when a dependency lookup doesn’t resolve (though I sometimes add it in local dev for testing/validation), at least as of #67.
4. As of #135, dependency resolution was expanded to be form-wide and match all possible nodes; there’s no case where a `null` reference **should** match a node and won’t.

I can imagine these potentially useful followup changes:

1. On parse, identify any path sub-expressions which **will never** resolve to any node in the form.
2. Short circuit lookup of such never-resolvable paths. There’s no sense walking the full form tree for something we know we won’t find!
3. Potentially warn when such never-resolvable paths are found. This wouldn’t be particularly useful for the `null` NameTest specifically (where the intent at least in WHO VA is clearly a null reference), but it could be useful for catching typos and other mistaken references like hierarchy confusion.

- Cases which previously exercised set-like behvaior implicitly are broken into individual tests, e.g. demonstrating cases where `current()` and `.` are treated the same way
- Adds an explicit set-like behavior test

This corrects the previous copypasta mistake, and makes the notes more general so they don’t overly influence reasoning about the gap in behavior

Two of the tests are currently marked failing:

2. This question caught a bug! I’ll fix in a subsequent commit.
4. This question suggested a valuable enhancement! I’ll timebox a solution to this, and expect to also have a fix for it in a subsequent commit.

This further clarifies that the intent is to identify where an expression **is** a translation call, not where an expression may contain such a call as any arbitrary sub-expression. As mentioned in the added JSDoc todo, it is possible we may want this in some future change. I think we should know more about whether it’s an expected use case before implementing it (as if it’s not an expected use case, it could be an indication of a form design mistake).

…to fix

… FilterExpr

… and add several related tests around the general concept.

…nt type