* Fix 9392, but for destructors: out-of-line defaulted destructors skipped everything after
Context:
```
struct S {
~S();
};
S::~S() = default;
void g() {
int j;
++j;
}
```
Everything after `S::~S() = default;` was skipped, so the uninitialized variables in g() weren't found.
Out-of-line destructors are useful e.g. when you have a forward declared unique_ptr in the .h,
and `= default` the destructor in the .cpp, so only the cpp needs to know the header for destructing
your unique_ptr (like in the pImpl-idiom)
* Fix unit test, by correctly fixing 10789
Previous commit broke this test, but also provided the tools for a cleaner fix
* Document current behaviour
* Rewrite control flow
* Fix deleted functions, which skipped everything after
`a::b f() = delete` triggered the final else in SymbolDatabase::addNewFunction,
which sets tok to nullptr, effectively skipping to the end of the stream.
* Remove troublesome nullptr, which skips every analysis afterwards
It was introduced in 0746c241 to fix a memory leak.
But setting tok to nullptr, effectively skipping to the end, seems not needed.
Previous commits fixes prevented some cases where you could enter the `else`.
This commit is more of a fall back.
* fixup! Fix deleted functions, which skipped everything after
`a::b f() = delete` triggered the final else in SymbolDatabase::addNewFunction,
which sets tok to nullptr, effectively skipping to the end of the stream.
* fixup! Fix deleted functions, which skipped everything after
`a::b f() = delete` triggered the final else in SymbolDatabase::addNewFunction,
which sets tok to nullptr, effectively skipping to the end of the stream.
* Make it heard when encountering unexpected syntax/tokens
Co-authored-by: Gerbo Engels <gerbo.engels@ortec-finance.com>
* Fix internalAstError with new
* Format
* nullptr check
* Add test for #11039
* Fix#11039 Empty AST with delete new / #11327 FP leakReturnValNotUsed with new and offset
* iwyu.yml: use debian:unstable to always get latest include-what-you-use
* cleaned up includes based on include-what-you-use
* mitigated include-what-you-use false positives
Currently sub-expressions like decltype(x){} break AST creation for
subsequent tokens in the whole expression. In some cases this triggers
validation checks in validateAst() and analysis on the file stops.
For example, code like this:
int x = decltype(0){} ? 0 : 1;
currently produces internalAstError.
To fix the issue iscpp11init_impl() was changed to recognize { preceded
by decltype(expr) as a start of C++11 brace initialization expression.
The previous fix for the issue (43b58dbc9e) didn't seem to actually fix
it because it added a check for noexcept without a condition, but when
AST is created noexcept always has a condition due to simplification
from "noexcept" to "noexcept(true)" in Tokenizer::simplifyKeyword().
The issue from the ticket couldn't be reproduced neither on 43b58dbc9e
nor on the previous commit, so it is hard to tell whether the fix was
effective or not.
The issue appeared again after a refactoring of AST code in ac67049661.
Test added with the original fix was unable to catch that because it
used testAst() helper function which skips most simplification steps.
To fix the issue we now check for noexcept with a condition and add a
proper regression test that:
1. Uses tokenizeAndStringify() to ensure that all simplifications are
performed before AST is created.
2. Parses the code snippet from the ticket, as having "if (cond)" is
crucial to reproducing the original issue (internalAstError).
Also fix AST creation for lambdas that have both constexpr and mutable
keywords.
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`.
gerboengels
chrchr-github
Oliver Stöneberg
Daniel Marjamäki
Paul Fultz II
PKEuS
Armin Müller
keinflue
dummyunit
orbitcowboy
IOBYTE
Ken-Patrick Lehrmann
shaneasd
Daniel Friedrich
PKEuS