Rust: restrict canonical path calculations

[redsun82]

No description provided.

[redsun82]

@hvitved could you lend me a hand here with the dataflow changes? I tried to preserve the implementation while shifting around the path resolution from Path to "stuff with paths" (e.g. PathExpr or RecordExpr and others), but it seems like it's not the case considering the new results in the local data flow tests.

[redsun82]

Seems like this is helping performance, although not by a great deal: end2end time went down with a median of around -4%, with some faster outliers:
https://github.com/github/codeql-dca-main/blob/data/redsun82/pr-18165-c46f44__nightly__nightly/reports/summaries/time.theme.md#end-to-end-time-per-source

[hvitved]

@hvitved could you lend me a hand here with the dataflow changes? I tried to preserve the implementation while shifting around the path resolution from Path to "stuff with paths" (e.g. PathExpr or RecordExpr and others), but it seems like it's not the case considering the new results in the local data flow tests.

Aren't the .expected changes merely the result of the improved TupleStructPat.toString implementation? (It would be easier to review, if that change was done as a separate commit).

[redsun82]

@hvitved could you lend me a hand here with the dataflow changes? I tried to preserve the implementation while shifting around the path resolution from Path to "stuff with paths" (e.g. PathExpr or RecordExpr and others), but it seems like it's not the case considering the new results in the local data flow tests.

Aren't the .expected changes merely the result of the improved TupleStructPat.toString implementation? (It would be easier to review, if that change was done as a separate commit).

I must say the thought crossed my mind, but then I thought that replacing a unique string representation with another should not multiply results, unless there's a toString inconsistency (which doesn't seem to be the case, as we track those with consistency queries). In any case, it makes sense to split out that improvement, I'll revert it here and open a new PR later.

[hvitved]

I must say the thought crossed my mind, but then I thought that replacing a unique string representation with another should not multiply results

Where do you see result multiplication?

[redsun82]

I must say the thought crossed my mind, but then I thought that replacing a unique string representation with another should not multiply results

Where do you see result multiplication?

😮 I hadn't noticed they went away after the previous merge from main including some of your new changes 🎉. I was referring to diffs such as this one for a previous version of this PR, but now it seems it's all good! I'll still split out the toString improvement for an easier PR.