You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
compiler: distinct array literals can share a constant pool key and produce incorrect results #71914
Hi Angular team! Two different array literals in the same template can share a constant pool key. The template compiles but returns the wrong result.
Minimal reproduction
Use this as a component template:
{{ ["a", "b"].length }}|{{ ['a","b'].length }}
Expected 2|1. Actual 2|2 in JIT and AOT. Reversing the expressions in JIT produces 1|1 instead of 1|2.
Cause and possible fix
GenericKeyFn.keyOf() wraps strings in quotes without escaping embedded quotes, giving both arrays the same key. Returning JSON.stringify(expr.value) in the string branch produced the expected result in local JIT and AOT tests. Relevant code in constant_pool.ts
Environment
Angular compiler 22.2.5, Node.js 24.22.2, macOS arm64. Regression status unknown.
Hi @halcyon-past, thanks for offering to help! I’ve already tested a possible fix locally, and I’d like to open a PR with a regression test. I’m waiting to hear what the maintainers think of the approach before opening it. Just wanted to give you a heads-up so we don’t duplicate work!
Thanks for the heads-up, @nagahara-naoki! Please go ahead—I'll hold off on opening a PR so we don't duplicate work.
One small note from looking at GenericKeyFn.keyOf(): the quoted object-key branch (if (entry.quoted) { key = "${key}"; }) right below has the same unescaped-quote collision issue (e.g., {'a":1,"b': 2} vs {"a": 1, "b": 2}), so using JSON.stringify(key) there as well might be worth including in your PR.
Hi @halcyon-past, thanks for holding off and for spotting the potential collision with quoted object keys! I’ll try your example locally and check whether the same fix works there too. If it does, I’ll include a regression test for it in the PR!
Activity
halcyon-past commentedon Nov 10, 2026
Hi! Could you please assign this issue to me? I'd like to work on fixing it and submit a PR with tests.
nagahara-naoki commentedon Nov 10, 2026
Hi @halcyon-past, thanks for offering to help! I’ve already tested a possible fix locally, and I’d like to open a PR with a regression test. I’m waiting to hear what the maintainers think of the approach before opening it. Just wanted to give you a heads-up so we don’t duplicate work!
halcyon-past commentedon Nov 10, 2026
Thanks for the heads-up, @nagahara-naoki! Please go ahead—I'll hold off on opening a PR so we don't duplicate work.
One small note from looking at
GenericKeyFn.keyOf(): the quoted object-key branch (if (entry.quoted) { key ="${key}"; }) right below has the same unescaped-quote collision issue (e.g.,{'a":1,"b': 2}vs{"a": 1, "b": 2}), so usingJSON.stringify(key)there as well might be worth including in your PR.nagahara-naoki commentedon Nov 10, 2026
Hi @halcyon-past, thanks for holding off and for spotting the potential collision with quoted object keys! I’ll try your example locally and check whether the same fix works there too. If it does, I’ll include a regression test for it in the PR!
fix(compiler): length-prefix string literals and quoted map keys in C…
fix(compiler): length-prefix string literals and quoted map keys in C…