Jave: Use force local to make parsing local after global regex finding.

[alexet]

With this the regex parsing becomes local.

The assumption is that strings in the base don't become regexs or stop being regexs. From what I have seen that doesn't seem likely.

[Copilot]

Pull Request Overview

This PR optimizes regex flow analysis in Java by making parsing local after global regex finding. The change uses forceLocal to localize the usedAsRegex predicate while maintaining the global regex finding capabilities.

Key changes:

• Refactors the usedAsRegex predicate to use local evaluation with forceLocal
• Extracts the original logic into a helper predicate usedAsRegexImpl
• Adds overlay[local] annotation to the main predicate

[Copilot]

There's a typo in the comment: 'repitition' should be 'repetition'.

[kaspersv]

Code change looks good. Do you have links to DCA experiments? Since we are moving the overlay frontier there is a risk of optimisation regressions under non-overlay evaluation, so I would expect a DCA experiment that shows no performance impact under non-overlay evaluation and a DCA experiment that shows little to no accuracy regression under overlay evaluation and possibly a speedup.

[alexet]

I just ran DCA and I think the results look food: https://github.com/github/codeql-dca-main/blob/data/alexet/pr-20378-220197__nightly__nightly-queries/reports/summaries/time.theme.md

[kaspersv]

Yes, timing results look good. There were extraction differences for smowton__kotlin@2ed108c2___buildless which is causing alert wobble and there is also the same issue with iSoron__uhabits@897a236__323e as in the TC overlay caller PR. Have you confirmed with the Java team that we can ignore these?

[alexet]

smowton states that the extractor errors can't possibly be caused by this PR so should be disregarded.