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`.
The template parameter is confusing simplifyUsing: it does not compute
properly the scope, and we end up replace "type" in "to_string" with
"void", then later "void" is removed and we have an internal error.
* Fix some false positive in loop forward analysis
In cases like:
```
bool b();
void f()
{
int val[50];
int i, sum=0;
for (i = 1; b() && i < 50; i++)
sum += val[i];
for (; i < 50; i++)
sum -= val[i];
}
```
The forward analysis assumed the second loop was entered, and we ended
up with false positive in it:
`Array 'val[50]' accessed at index 50, which is out of bounds`
* Fix style
Daniel Marjamäki
Ken-Patrick Lehrmann
firewave
Paul Fultz II
orbitcowboy
Simon Martin
Sebastian