borinquenkid commented on PR #15971:
URL: https://github.com/apache/grails-core/pull/15971#issuecomment-4942025508
@bito-code-review Good catch, and correct — the detector only matched the
immediate coercion expression, so this slipped through:
```groovy
def g = "from Book where name = ${x}" // g: still a live GString
String q = g // flattened HERE, uncaught
Book.executeQuery(q)
```
Fixed in 46c4ba2486: replaced the single `flattenedStringVars` set with a
two-state model (`LIVE_GSTRING` / `FLATTENED`) that resolves through
`VariableExpression` references, so the flattening point is found correctly
regardless of how many variable-to-variable hops separate the original
`GString` literal from the query call.
Added regression tests for the exact case above, a two-hop alias chain (`def
g = ...; def h = g; String q = h`), `.toString()` called on an alias, and
re-aliasing an already-flattened variable — all in
`GormQuerySafetyTransformerSpec`. Full `grails-datamapping-core`,
`grails-data-hibernate7-core`, and `grails-data-hibernate5-core` suites still
pass with zero regressions.
Still out of scope by design (see the class Javadoc / PR description): a
flattened `String` built inside a *different* method and returned is invisible
to this check, since the analysis is intraprocedural.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
