[clang][dataflow] Fix result object location for builtin `<=>`. (#88726)

The newly added test causes an assertion failure in
`PropagateResultObject()`
without the fix added here.

[clang][dataflow] Reland #87320: Propagate locations from result objects to initializers. (#88316)

This relands #87320 and additionally removes the now-unused function
`isOriginalRecordConstructor()

[clang][dataflow] Reland #87320: Propagate locations from result objects to initializers. (#88316)

This relands #87320 and additionally removes the now-unused function
`isOriginalRecordConstructor()`, which was causing buildbots to fail.

show more ...

Revert "[clang][dataflow] Propagate locations from result objects to initializers." (#88315)

Reverts llvm/llvm-project#87320

This is causing buildbots to fail because
`isOriginalRecordConstructo

Revert "[clang][dataflow] Propagate locations from result objects to initializers." (#88315)

Reverts llvm/llvm-project#87320

This is causing buildbots to fail because
`isOriginalRecordConstructor()` is now unused.

show more ...

[clang][dataflow] Propagate locations from result objects to initializers. (#87320)

Previously, we were propagating storage locations the other way around,
i.e.
from initializers to result objects,

[clang][dataflow] Propagate locations from result objects to initializers. (#87320)

Previously, we were propagating storage locations the other way around,
i.e.
from initializers to result objects, using `RecordValue::getLoc()`. This
gave
the wrong behavior in some cases -- see the newly added or fixed tests
in this
patch.

In addition, this patch now unblocks removing the `RecordValue` class
entirely,
as we no longer need `RecordValue::getLoc()`.

With this patch, the test `TransferTest.DifferentReferenceLocInJoin`
started to
fail because the framework now always uses the same storge location for
a
`MaterializeTemporaryExpr`, meaning that the code under test no longer
set up
the desired state where a variable of reference type is mapped to two
different
storage locations in environments being joined. Rather than trying to
modify
this test to set up the test condition again, I have chosen to replace
the test
with an equivalent test in DataflowEnvironmentTest.cpp that sets up the
test
condition directly; because this test is more direct, it will also be
less
brittle in the face of future changes.

show more ...

[clang][dataflow] Bail out if input is Objective-C++. (#86479)

We only ever intended to support C++, but the condition we were testing
allowed
Objective-C++ code by mistake.

[clang][dataflow] Fix crash when analyzing a coroutine (#85957)

A coroutine function body (`CoroutineBodyStmt`) may have null children,
which causes `isa` to segfault.

[clang][dataflow] Model assignment to derived class from base. (#85064)

This is a relatively rare case, but

- It's still nice to get this right,
- We can remove the special case for this in
`VisitC

[clang][dataflow] Model assignment to derived class from base. (#85064)

This is a relatively rare case, but

- It's still nice to get this right,
- We can remove the special case for this in
`VisitCXXOperatorCallExpr()` (that
simply bails out), and
- With this in place, I can avoid having to add a similar special case
in an
upcoming patch.

show more ...

[clang][dataflow] Fix `getResultObjectLocation()` on `CXXDefaultArgExpr`. (#85072)

This patch includes a test that causes an assertion failure without the
other
changes in this patch.

[clang][dataflow] Add context-sensitive test for returning a record by value. (#84317)

I'm making some changes to `Environment::getResultObjectLocation()`,
with the
ultimate goal of eliminating `Rec

[clang][dataflow] Add context-sensitive test for returning a record by value. (#84317)

I'm making some changes to `Environment::getResultObjectLocation()`,
with the
ultimate goal of eliminating `RecordValue` entirely, and I'd like to
make sure
I don't break this behavior (and I've realized we don't have a test for
it yet).

show more ...

[clang][dataflow] When analyzing ctors, don't initialize fields of `*this` with values. (#84164)

This is the constructor's job, and we want to be able to test that it
does this.

[clang][dataflow] Correctly treat empty initializer lists for unions. (#82986)

This fixes a crash introduced by
https://github.com/llvm/llvm-project/pull/82348
but also adds additional handling to m

[clang][dataflow] Correctly treat empty initializer lists for unions. (#82986)

This fixes a crash introduced by
https://github.com/llvm/llvm-project/pull/82348
but also adds additional handling to make sure that we treat empty
initializer
lists for both unions and structs/classes correctly (see tests added in
this
patch).

show more ...

[clang][dataflow] Skip array types when handling InitListExprs. (#83013)

Crashes resulted from single-element InitListExprs for arrays with
elements of a record type after #80970.

Revert "[clang][dataflow] Correctly handle `InitListExpr` of union type." (#82856)

Reverts llvm/llvm-project#82348, which caused crashes when analyzing
empty InitListExprs for unions, e.g.

```cc

Revert "[clang][dataflow] Correctly handle `InitListExpr` of union type." (#82856)

Reverts llvm/llvm-project#82348, which caused crashes when analyzing
empty InitListExprs for unions, e.g.

```cc
union U {
double double_value;
int int_value;
};

void target() {
U value;
value = {};
}
```

Co-authored-by: Samira Bazuzi <bazuzi@users.noreply.github.com>

show more ...

[clang][dataflow] Correctly handle `InitListExpr` of union type. (#82348)

[clang][dataflow] Fix crash on unions introduced in ba279934c6ab09d5394a89d8318651aefd8d565b (#81918)

The commit was itself a crash fix, but inadvertently changed the
behavior for unions, which res

[clang][dataflow] Fix crash on unions introduced in ba279934c6ab09d5394a89d8318651aefd8d565b (#81918)

The commit was itself a crash fix, but inadvertently changed the
behavior for unions, which results in crashes.

show more ...

[dataflow] Fix crash when InitListExpr is not a prvalue (#80970)

[dataflow] CXXOperatorCallExpr equal operator might not be a glvalue (#80991)

Although in a normal implementation the assumption is reasonable, it
seems that some esoteric implementation are not re

[dataflow] CXXOperatorCallExpr equal operator might not be a glvalue (#80991)

Although in a normal implementation the assumption is reasonable, it
seems that some esoteric implementation are not returning a T&. This
should be handled correctly and the values be propagated.

---------

Co-authored-by: martinboehme <mboehme@google.com>

show more ...

[NFC] Correct C++ standard names (#81421)

[clang][dataflow] fix assert in `Environment::getResultObjectLocation` (#79608)

When calling `Environment::getResultObjectLocation` with a
CXXOperatorCallExpr that is a prvalue, we just hit an asse

[clang][dataflow] fix assert in `Environment::getResultObjectLocation` (#79608)

When calling `Environment::getResultObjectLocation` with a
CXXOperatorCallExpr that is a prvalue, we just hit an assert because no
record was ever created.

---------

Co-authored-by: martinboehme <mboehme@google.com>

show more ...

[clang][dataflow] Process terminator condition within `transferCFGBlock()`. (#78127)

In particular, it's important that we create the "fallback" atomic at
this point
(which we produce if the trans

[clang][dataflow] Process terminator condition within `transferCFGBlock()`. (#78127)

In particular, it's important that we create the "fallback" atomic at
this point
(which we produce if the transfer function didn't produce a value for
the
expression) so that it is placed in the correct environment.

Previously, we processed the terminator condition in the
`TerminatorVisitor`,
which put the fallback atomic in a copy of the environment that is
produced as
input for the _successor_ block, rather than the environment for the
block
containing the expression for which we produce the fallback atomic.

As a result, we produce different fallback atomics every time we process
the
successor block, and hence we don't have a consistent representation of
the
terminator condition in the flow condition.

This patch includes a test (authored by ymand@) that fails without the
fix.

show more ...

[clang][dataflow] Make cap on block visits configurable by caller. (#77481)

Previously, we hard-coded the cap on block visits inside the framework.
This
patch enables the caller to specify the cap i

[clang][dataflow] Make cap on block visits configurable by caller. (#77481)

Previously, we hard-coded the cap on block visits inside the framework.
This
patch enables the caller to specify the cap in the APIs for running an
analysis.

show more ...

[clang][dataflow] Treat comma operator correctly in `getResultObjectLocation()`. (#78427)

[clang][dataflow] Consider `CXXDefaultInitExpr` to be an "original record ctor". (#78423)

The CFG doesn't contain a CFGElement for the
`CXXDefaultInitExpr::getInit()`, so
it makes sense to consider

[clang][dataflow] Consider `CXXDefaultInitExpr` to be an "original record ctor". (#78423)

The CFG doesn't contain a CFGElement for the
`CXXDefaultInitExpr::getInit()`, so
it makes sense to consider the `CXXDefaultInitExpr` to be the expression
that
originally constructs the object.

show more ...

Revert "[clang][dataflow] Process terminator condition within `transferCFGBlock()`." (#77895)

Reverts llvm/llvm-project#77750

[clang][dataflow] Process terminator condition within `transferCFGBlock()`. (#77750)

In particular, it's important that we create the "fallback" atomic at
this point
(which we produce if the trans

[clang][dataflow] Process terminator condition within `transferCFGBlock()`. (#77750)

In particular, it's important that we create the "fallback" atomic at
this point
(which we produce if the transfer function didn't produce a value for
the
expression) so that it is placed in the correct environment.

Previously, we processed the terminator condition in the
`TerminatorVisitor`,
which put the fallback atomic in a copy of the environment that is
produced as
input for the _successor_ block, rather than the environment for the
block
containing the expression for which we produce the fallback atomic.

As a result, we produce different fallback atomics every time we process
the
successor block, and hence we don't have a consistent representation of
the
terminator condition in the flow condition.

This patch includes a test (authored by ymand@) that fails without the
fix.

show more ...