In some cases, the condition of the ternary operator is assigned a known
value after the two possible results, and in such cases, we would not
take the opportunity to assign a value to the ternary operator (and to
the other parents in the ast).
This patch adds this capability.
Teaching cppcheck about `BOOST_THROW_EXCEPTION` and
`boost::throw_exception`, and using noreturn information from libraries
in value flow.
This fixes false positive nullPointerRedundantCheck with the following
code:
```
void throwexception(int * buf)
{
if (!buf)
boost::throw_exception(std::bad_alloc());
*buf = 0;
}
```
* 9768: Fix ast with throw in the middle of return
```
int f(bool x)
{
return x ? 0 : throw 0;
}
```
The `throw` part was not included in the ast, leading to an invalid
ternary operator.
* 8526: Fix ast construction for ternary operator
This tries to decide a bit more properly when ':' can be part of a
ternary operator. More precisely, there are some times when we want to
delay the construction of the ast for ':', so that it is place
accordingly to the matching '?'.
Typically, this fixes an issue with
`return val < 0 ? throw 1 : val;`,
where the ast for ':' would be constructed during as part of the
`throw`, and the ast for `?` would be invalid.
This patch is a bit of a hardcode, stating that we don't expect ':'
inside a throw, unless there is a complete ternary operator in there
(there can't be a range based for loop, a case in a switch). When we
reach ':', we know we are and the end of the `throw`.
This tries to decide a bit more properly when ':' can be part of a
ternary operator. More precisely, there are some times when we want to
delay the construction of the ast for ':', so that it is place
accordingly to the matching '?'.
Typically, this fixes an issue with
`return val < 0 ? throw 1 : val;`,
where the ast for ':' would be constructed during as part of the
`throw`, and the ast for `?` would be invalid.
This patch is a bit of a hardcode, stating that we don't expect ':'
inside a throw, unless there is a complete ternary operator in there
(there can't be a range based for loop, a case in a switch). When we
reach ':', we know we are and the end of the `throw`.
Paul
Daniel Marjamäki
Ken-Patrick Lehrmann
orbitcowboy
firewave