Unable to start an expression with '/'

[tanhauhau]

Describe the bug

Using a regex in an expression lead to parsing error:

Unexpected block closing tag
100:                   <div>{ /^[A-Za-z ]+$/.test('Some String value') ? 'foo' : 'bar' }</div>
                                       ^

that's because the parser treat { / as the closing of the logic block, eg: {/if}.

parsing the mustache as expression should have higher priority than parsing it as a closing logic block, eg: {/if}, {/await} or {/each}.

Severity

A workaround is to not start the expression with /, replace it with a variable if possible, for the example above a workaround would be:

<script>
   let regex = /^[A-Za-z ]+$/;
</script>

<div>{ regex.test('Some String value') ? 'foo' : 'bar' }</div>

Additional context
Add any other context about the problem here.

[pngwn]

I don't really see an easy way around this, {/if}/} is a perfectly valid regex that would be virtually impossible to guard against unless we starting backtracking. Every time we came across a {/ we would have to assume it could be a child expression of the current branch before falling back to parsing it as a block end statement. This would be wasted work the majority of the time.

You can also solve this just by wrapping in parens, the following both work fine:

<div>{ (/^[A-Za-z ]+$/.test('Some String value') ? 'foo' : 'bar') }</div>

<div>{ (/^[A-Za-z ]+$/).test('Some String value') ? 'foo' : 'bar' }</div>

[Conduitry]

I'm labeling this as a docs issue, because I really don't think we want to try parsing this differently.

That said, I'm not actually sure where in the docs this should go, or whether it even makes sense to mention, as it seems to have a high ratio of expected-confusion-caused-by-reading-this-explanation to expected-confusion-caused-by-running-into-this-limitation.

[benmccann]

I somewhat expected this to happen with all expressions, but <button disabled={/^[A-Za-z ]+$/.test(value)}>...</button> works as does {@html /^[A-Za-z ]+$/.test(value)} so maybe it really is just text expressions as suggested in the proposed docs PR #5640

[pngwn]

Yeah it is i think. The issue is that we can't easily disambiguate between a closing blog {/if} and a similar expression: {/if}. Attribute expressions, and void block expressions like this don't have that issue, as a closing block is not valid in that context.