https://bugs.kde.org/show_bug.cgi?id=370641
RJVB <rjvber...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kf...@kde.org
See Also| |https://bugs.kde.org/show_b
| |ug.cgi?id=363893
--- Comment #2 from RJVB <rjvber...@gmail.com> ---
Found it, this is another example of the danger of using Q_ASSERT :
ClangFixits ClangProblem::allFixits() const
{
ClangFixits result;
result << m_fixits;
for (const IProblem::Ptr& diagnostic : diagnostics()) {
const Ptr problem(dynamic_cast<ClangProblem*>(diagnostic.data()));
Q_ASSERT(problem);
result << problem->allFixits();
}
return result;
}
a dynamic_cast can fail even if diagnostic.data() != NULL, for instance because
of (or related to) the issue reported in ticket 363893.
When code is built in "production" mode, Q_ASSERTs are noops, and this leads
directly to the crash and backtrace shown above.
I cannot assess to what extent a NULL problem should cause KDevelop to abort. I
am currently trying the fix below, and with that implementation I see exactly
the same (popup error reporting) as I see on Linux. Curiously the warning
hasn't been printed yet, even.
ClangFixits ClangProblem::allFixits() const
{
ClangFixits result;
result << m_fixits;
for (const IProblem::Ptr& diagnostic : diagnostics()) {
const Ptr problem(dynamic_cast<ClangProblem*>(diagnostic.data()));
Q_ASSERT(problem);
if (problem) {
result << problem->allFixits();
} else {
qWarning() << Q_FUNC_INFO << "dynamic cast to ClangProblem failed
of" << diagnostic.data();
}
}
return result;
}
--
You are receiving this mail because:
You are watching all bug changes.
