A string-valued requested-helper local named second keeps its history in the numeric helper store #351

What happens

In a request.security helper, a local of string type named second has its history (second[1]) emitted against the numeric helper store _security_helper_series_, while a local of the same shape with any other name I tried (first, aa) uses the string store _security_helper_series_str_. second is also the name of a Pine built-in variable. I did not investigate the cause; the name may resolve to the built-in's numeric type during type inference.

Reproduction (codegen main, commit f84d312)

//@version=6
strategy("helper words")
h() =>
    second = str.tostring(close)
    bb = second[1]
    second + bb
v = request.security(syminfo.tickerid, "60", h())
plot(str.length(v))

Reading the helper stores out of the emitted C++ for this source: the history of the helper locals is in _security_helper_series_ (numeric). The same source with second replaced by first or by aa has it in _security_helper_series_str_. The result is the same when the script also contains n = input.int(3) and z = close[n].

Expected

The string store, as for every other name.

Notes

• Found while testing pull request 348 (it adds a test that tries each introduced word as a helper local, and that one combination had to be left out); it is not caused by that change: the run above is on main.
• Only the names first, second and aa were tried.

🤖 Generated with Claude Code