RFR: 8344942: Template-Based Testing Framework [v61]
Emanuel Peter
epeter at openjdk.org
Sun Jun 1 16:14:06 UTC 2025
On Sat, 31 May 2025 11:48:39 GMT, Emanuel Peter <epeter at openjdk.org> wrote:
>> @chhagedorn
>> The current parsing/regex-ing is relatively simple. We only parse the "valid" cases, so the description above is still relevant.
>> Your example `$1var` is not a valid pattern, so the regex does not match, and there is no replacement. Sadly, in Java `$1var` is a valid variable name, so there is some chance that the user makes a mistake and gets tripped up by this.
>>
>> If the user does a call to `let` or `$` with such a bad string `1var`, then they get a `RendererException`.
>>
>> The question is this:
>> Should I really try to parse these "bad" patterns, just to validate them as well? All solutions I can think of are really complicated. Is it worth it? Or is it just a mistake by the user, and so the matching does not happen, and that is the users problem?
>
> FYI: `$$var` the first `$` is not a valid pattern, so it is not replaced. But `$var` is, and so that part gets replaced. The result is `$var_1`, which sadly happens to also be valid Java code.
I think I just need to rewrite the way I parse and replace the strings. Doing a simple regex with `replaceAll` does not work if we also want to allow "bad" patterns such as `$$var` to be parsed, because of ambiguity.
My new idea: split the string by `#` and `$`. The first string is just a regular string, because it has no `#` or `$` before it. But all others should start with either a `name` or `{name}` pattern. I should also do the `#` and `$` replacement in a single pass, so that we cannot have one replacement influence the other, i.e. that we have no "replacement injection" issues that may be confusing if anybody ever trips over it.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24217#discussion_r2119291366
More information about the hotspot-compiler-dev
mailing list