[owen-mc]

Replace pragma[noinline] with pragma[nomagic] on ExtractedOrExternalFile.hasBuildConstraints() so that build-constrained files are computed bottom-up rather than using demand specialization.

Motivation

On the aws/aws-sdk-go database used for testing, there are only 24 files containing build constraints. However, the existing demand-specialized plan propagates demands from call targets and function bodies through location joins, producing approximately 15–19 million intermediate tuples before filtering by build-constraint comments.

With pragma[nomagic], the predicate instead starts from build-constraint comments and finds their files directly. Its evaluation processes 29 tuples and returns the 24 build-constrained files.

DCA issue

Nightly DCA experiments repeatedly reported tuple-sum changes for:

Files::ExtractedOrExternalFile.hasBuildConstraints/0#4828fb61#b

These occurred when analyzing identical source code with effectively unchanged CodeQL code. Repeated evaluations of the same query and database reproduced the variation: with fine-grained parallelism, the recorded intermediate tuple counts depend on worker scheduling and duplicate handling, despite unchanged query results.

This change removes the large, schedule-dependent join rather than changing DCA's metric or disabling parallel evaluation. The replacement plan consistently recorded 29 tuples in the repeated local evaluations.

[owen-mc]

I ran DCA. Tuple sums for that predicate seem much improved. There is a result for Log ERROR lines, per source (v1) that I need to look into.

[Copilot]

🟢 Approval recommended

The localized refactor preserves predicate semantics while establishing the intended evaluation boundary.

No open issues 🎉

What changed in this PR

Stabilizes Go build-constraint evaluation to reduce expensive location joins and recurring DCA noise without changing results.

Changes:

• Adds a private bottom-up helper using pragma[nomagic].
• Preserves demand specialization on the public hasBuildConstraints() predicate.

File	Description
go/​ql/​lib/​semmle/​go/​Files.qll	Separates build-constraint discovery from caller demand propagation.

_{Review effort: Max}

[owen-mc]

I couldn't find the Log ERROR lines, per source (v1) results in the actions logs.

[owen-mc]

I previously tried having both pragma[noinline] and pragma[nomagic] (which I suspect now is probably redundant), and found it slower, hence why I came up with what was in this PR. But maybe I made a mistake because I just tried your suggestion and it wasn't slower. I've force-pushed to just use pragma[nomagic]. I've started another DCA run.

[hvitved]

I previously tried having both pragma[noinline] and pragma[nomagic] (which I suspect now is probably redundant), and found it slower, hence why I came up with what was in this PR. But maybe I made a mistake because I just tried your suggestion and it wasn't slower. I've force-pushed to just use pragma[nomagic]. I've started another DCA run.

Yes, nomagic implies noinline.

[owen-mc]

DCA is fine: no significant change to the overall analysis time, but a big decrease in tuple sums for one predicate.