Before the fix:
```
Pipeline standard for AVRule79::exprReleases/3#e849cdd3@f2995ebb was evaluated in 5 iterations totaling 168745ms (delta sizes total: 12583).
85855 ~0% {2} r1 = SCAN `AVRule79::exprReleases/3#e849cdd3#prev_delta` OUTPUT In.1, In.2
85855 ~0% {2} r2 = JOIN r1 WITH `AVRule79::exprOrDereference/1#c20425a1_10#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
115767 ~6% {2} | JOIN WITH `ASTValueNumbering::GVN.getAnExpr/0#dispred#a14f45bf_10#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
333369 ~18% {2} | JOIN WITH `ASTValueNumbering::GVN.getAnExpr/0#dispred#a14f45bf` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
266264 ~204% {2} | JOIN WITH `Access::Access.getTarget/0#dispred#cf25c8aa` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
16379 ~21% {3} | JOIN WITH `Function::Function.getParameter/1#dispred#200dcf26_201#join_rhs` ON FIRST 1 OUTPUT Rhs.2, Lhs.1, Rhs.1
13117819221 ~0% {4} r3 = JOIN r2 WITH `Call::Call.getArgument/1#dispred#ada436ba_102#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.2, Lhs.1, Rhs.2
10477 ~3% {3} | JOIN WITH `Call::FunctionCall.getTarget/0#dispred#935da4c5` ON FIRST 2 OUTPUT Lhs.0, Lhs.3, Lhs.2
13117819221 ~1% {4} r4 = JOIN r2 WITH `Call::Call.getArgument/1#dispred#ada436ba_102#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.1, Lhs.2, Rhs.2
13022632157 ~1% {5} | JOIN WITH `Call::FunctionCall.getTarget/0#dispred#935da4c5` ON FIRST 1 OUTPUT Rhs.1, Lhs.2, Lhs.1, Lhs.0, Lhs.3
3720 ~70% {3} | JOIN WITH `#MemberFunction::MemberFunction.getAnOverridingFunction/0#dispred#a6e65b9ePlus` ON FIRST 2 OUTPUT Lhs.3, Lhs.4, Lhs.2
115767 ~6% {2} r5 = JOIN r1 WITH `ASTValueNumbering::GVN.getAnExpr/0#dispred#a14f45bf_10#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
333367 ~20% {3} | JOIN WITH `ASTValueNumbering::GVN.getAnExpr/0#dispred#a14f45bf` ON FIRST 1 OUTPUT Rhs.1, _, Lhs.1
333367 ~12% {3} | REWRITE WITH Out.1 := 85
4 ~0% {2} | JOIN WITH exprs ON FIRST 2 OUTPUT Lhs.0, Lhs.2
4 ~100% {2} | JOIN WITH `Expr::Expr.getEnclosingFunction/0#dispred#3960f06c` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
0 ~0% {2} r6 = JOIN r5 WITH `Call::FunctionCall.getTarget/0#dispred#935da4c5_10#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
0 ~0% {2} r7 = JOIN r5 WITH `#MemberFunction::MemberFunction.getAnOverridingFunction/0#dispred#a6e65b9ePlus#swapped` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
0 ~0% {2} | JOIN WITH `Call::FunctionCall.getTarget/0#dispred#935da4c5_10#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
0 ~0% {2} r8 = r6 UNION r7
0 ~0% {3} | JOIN WITH `Call::Call.getQualifier/0#dispred#7d175544` ON FIRST 1 OUTPUT Rhs.1, Lhs.1, Lhs.0
0 ~0% {3} | JOIN WITH `AVRule79::exprOrDereference/1#c20425a1_10#join_rhs` ON FIRST 1 OUTPUT Lhs.2, Rhs.1, Lhs.1
14197 ~18% {3} r9 = r3 UNION r4 UNION r8
12615 ~3% {3} | AND NOT `AVRule79::exprReleases/3#e849cdd3#prev`(FIRST 3)
return r9
```
After:
```
Pipeline standard for AVRule79::exprReleases/3#e849cdd3@13dead04 was evaluated in 5 iterations totaling 68ms (delta sizes total: 12551).
85855 ~0% {2} r1 = SCAN `AVRule79::exprReleases/3#e849cdd3#prev_delta` OUTPUT In.1, In.2
85855 ~0% {2} r2 = JOIN r1 WITH `AVRule79::exprOrDereference/1#c20425a1_10#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
115767 ~6% {2} | JOIN WITH `ASTValueNumbering::GVN.getAnExpr/0#dispred#a14f45bf_10#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
333443 ~18% {2} | JOIN WITH `ASTValueNumbering::GVN.getAnExpr/0#dispred#a14f45bf` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
265872 ~204% {2} | JOIN WITH `Access::Access.getTarget/0#dispred#cf25c8aa` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
16399 ~27% {3} | JOIN WITH `Function::Function.getParameter/1#dispred#200dcf26_201#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.1, Rhs.2
10489 ~1% {3} r3 = JOIN r2 WITH `Call::FunctionCall.getTarget/0#dispred#935da4c5_10#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.2, Lhs.1
1558 ~80% {3} r4 = JOIN r2 WITH `#MemberFunction::MemberFunction.getAnOverridingFunction/0#dispred#a6e65b9ePlus#swapped` ON FIRST 1 OUTPUT Rhs.1, Lhs.1, Lhs.2
2196 ~7% {3} | JOIN WITH `Call::FunctionCall.getTarget/0#dispred#935da4c5_10#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.2, Lhs.1
12685 ~3% {3} r5 = r3 UNION r4
12581 ~3% {3} | JOIN WITH `Call::Call.getArgument/1#dispred#ada436ba` ON FIRST 2 OUTPUT Lhs.0, Rhs.2, Lhs.2
115767 ~6% {2} r6 = JOIN r1 WITH `ASTValueNumbering::GVN.getAnExpr/0#dispred#a14f45bf_10#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
333443 ~20% {3} | JOIN WITH `ASTValueNumbering::GVN.getAnExpr/0#dispred#a14f45bf` ON FIRST 1 OUTPUT Rhs.1, _, Lhs.1
333443 ~12% {3} | REWRITE WITH Out.1 := 85
4 ~0% {2} | JOIN WITH exprs ON FIRST 2 OUTPUT Lhs.0, Lhs.2
4 ~100% {2} | JOIN WITH `Expr::Expr.getEnclosingFunction/0#dispred#3960f06c` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
0 ~0% {2} r7 = JOIN r6 WITH `Call::FunctionCall.getTarget/0#dispred#935da4c5_10#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
0 ~0% {2} r8 = JOIN r6 WITH `#MemberFunction::MemberFunction.getAnOverridingFunction/0#dispred#a6e65b9ePlus#swapped` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
0 ~0% {2} | JOIN WITH `Call::FunctionCall.getTarget/0#dispred#935da4c5_10#join_rhs` ON FIRST 1 OUTPUT Rhs.1, Lhs.1
0 ~0% {2} r9 = r7 UNION r8
0 ~0% {3} | JOIN WITH `Call::Call.getQualifier/0#dispred#7d175544` ON FIRST 1 OUTPUT Rhs.1, Lhs.1, Lhs.0
0 ~0% {3} | JOIN WITH `AVRule79::exprOrDereference/1#c20425a1_10#join_rhs` ON FIRST 1 OUTPUT Lhs.2, Rhs.1, Lhs.1
12581 ~3% {3} r10 = r5 UNION r9
12576 ~3% {3} | AND NOT `AVRule79::exprReleases/3#e849cdd3#prev`(FIRST 3)
return r10
```
This will enable us to support non-type template parameters, which we
currently do not support, and error template parameters, which might
become relevant in the `build-mode: none` context.
This is used as textual includes in several projects for macro
metaprogramming, for example in `llvm-project` and in `swift` (and since
some time in our internal codebase as well).
Replace with link to the same article on devblogs.microsoft.com. Unfortunately, blogs.msdn.com does not automatically redirect to the new location, making this replacement necessary.
By moving a disjunct outside the scope of an `exists(Function f`
variable it doens't use, the code becomes clearer and can be optimized
better.
The CP in the QL code did not lead to a CP at evaluation time since the
optimizer was smart enough to compensate for it:
376161 ~37597630% {0} r1 = SCAN functions OUTPUT {}
1 ~0% {0} r2 = STREAM DEDUP r1
Before this change, the largest tuple count in `leakedInSameMethod` on
bitcoin/bitcoin was 2M. Now it's 400k.
The `cpp/local-variable-hides-global-variable` doesn't seem right as a
warning without some additional context. For example, is the local
variable and the global variable used in the same function body, and
do they have similar enough types that it would be possible to confuse
them.
The `cpp/missing-header-guard` query enforces good style and helps with
compilation speed, but AFAIK it has never flagged a correctness issue.
Therefore I think it should be a recommendation.
