Repository navigation
A Pine variable named like a generated script-state member ends in an uncaught AssertionError #350
Description
What happens
A requested helper whose local variable is named like one of the generator's own script-state members (_security_helper_series_, _security_helper_series_str_) makes transpile() raise
AssertionError: duplicate generated script-state member: _security_helper_series_
(raised in pineforge_codegen/codegen/emit_top.py), not a typed CompileError diagnostic. A caller that handles CompileError and treats everything else as an internal failure sees a crash for a valid-looking script.
Reproduction (codegen main, commit f84d312)
//@version=6
strategy("helper words")
n = input.int(3)
z = close[n]
h() =>
_security_helper_series_ = close
bb = nz(_security_helper_series_[1])
_security_helper_series_ + bb
v = request.security(syminfo.tickerid, "60", h())
plot(v)
transpile(source) raises the AssertionError above. With a string-valued local (_security_helper_series_str_ = str.tostring(close) and a plot of str.length(v)) the same happens for the name _security_helper_series_str_; with the name _security_helper_series_ it happens for both the numeric and the string variant. The same source with the local named aa transpiles. (The string store member exists only when the script has a string series, so the numeric variant with the name _security_helper_series_str_ transpiles.)
Expected
Either a typed diagnostic, like the other refusals of reserved names, or a rename of the Pine variable by the safe-name mechanism, which already renames names that collide with emitted C++ names.
Notes
- Found while testing pull request 348; it is not caused by that change. It is likely to apply to other generated member names; I have not checked them.
- The two names above are the only ones I tried.
🤖 Generated with Claude Code
Activity
Reserve the numbered tuple element bindings, and pin the string-histo…
luisleo526 commentedon Nov 9, 2026
Status at v1.11.0: the main fix is in v1.11.0 (#355): a variable named like an internal member is renamed and no longer stops with an internal error. One remaining name form (the element names of a tuple result) is planned for v1.11.1. This issue stays open for that form.
luisleo526 commentedon Nov 13, 2026
Status 2026-11-13: the main fix shipped in 1.11.0. The remaining form (the element names of a tuple result) is not fixed yet; its date is posted here by 2026-11-14.
🤖 Generated with Claude Code
luisleo526 commentedon Nov 14, 2026
Status 2026-11-14: work on the fix is under way, but its date is not established yet. We will post the date here by 2026-11-14 18:00 (UTC+8).
luisleo526 commentedon Nov 14, 2026
Status 2026-11-14 17:00 (UTC+8): the main case was fixed in 1.11.0. For the remaining part (the element names of a tuple result), we do not yet have a failing example that reproduces on the current version, so there is no date yet. If you have a script that still fails, please post it here. We will post the next update here by 2026-11-15 12:00 (UTC+8).
luisleo526 commentedon Nov 15, 2026
Status 2026-11-15 11:10 (UTC+8): we have a candidate fix for the remaining name collisions between script names and generated member names, and it is being verified on current main. The verification is not finished, so there is no date yet. If you have a script that still fails on 1.12.0, please post it here; we will add it to the tests. We will post the merge commit here when the fix lands.