- 12 Oct, 2020 3 commits
-
-
Rolf Eike Beer authored
-
Rolf Eike Beer authored
-
Rolf Eike Beer authored
Be less strict about the default assert message, so it can match also custom assert messages. Also add an expression that matches the assert_perror() output of glibc.
-
- 11 Oct, 2020 2 commits
-
-
Script Kiddy authored
In case of conflict in i18n, keep the version of the branch "ours" To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
-
Script Kiddy authored
-
- 07 Oct, 2020 22 commits
-
-
Igor Kushnir authored
-
Igor Kushnir authored
For many years I thought that KDevelop's Stop toolbar menu was broken. Today after digging into the relevant code and documentation I found out that one has to press and hold the button for a few seconds for the submenu to show up. From the documentation to KActionMenu::setDelayed(): Remember that if the "main" action (the toolbar button itself) cannot be clicked, then you should call setDelayed(false). This is clearly the case for the Stop menu button and for the Tool Views menu button (which can be added to the Main Toolbar through Configure Toolbars dialog): clicking these buttons has no effect.
-
Igor Kushnir authored
When a job fails, ThreadWeaver::QObjectDecorator emits both failed() and done() signals. BackgroundParser::parseComplete() is connected to both. So when a ParseJob fails, parseComplete() is called twice for the same job. The most obvious consequence is the too great value of d->m_doneParseJobs. Two classes derived from ParseJob - CMakeParseJob and QmlJsParseJob - call ParseJob::abortJob() when they are aborted, which makes ParseJob::success() return false and thus causes QObjectDecorator to emit both signals. In order to test what happens when the bug is triggered, I edited CMakeParseJob::run() code to unconditionally call `abortJob(); return;` after the `if (!package.isEmpty()) {` line. KDevelop seems to handle this well, but there are lots of relevant debug messages in the log: kdevplatform.language: m_doneParseJobs larger than m_maxParseJobs: 0 -1 kdevplatform.language: m_doneParseJobs larger than m_maxParseJobs: 1 0 The simple fix is to connect only to the &ThreadWeaver::QObjectDecorator::done signal. Its documentation states: "This signal is emitted when the job has been finished (no matter if it succeeded or not)."
-
Igor Kushnir authored
When a user closes a project while its associated CTestFindJob is still working, the job is not notified and keeps running. After that, when BackgroundParser eventually parses all documents requested by the job, the job calls TestController::addTestSuite(). Inside this call the CTestSuite::project() pointer is dereferenced in TestView::addTestSuite() => TestView::itemForProject(), which causes a segmentation fault. Ideally all associated CTestFindJob-s should be killed just before or just after a project is closed to revert their no longer useful requests to BackgroundParser as soon as possible. However, reliably detecting that the project is no longer open is not straightforward, especially if the project opening is aborted or the project is closed even before a CTestFindJob is created. My implementation of such a proper fix is intertwined with several other CTest-, TestController- and TestView-related fixes. The combined fix will be so large that it won't fit into the 5.6 branch. So this commit implements a simple temporary workaround for the fairly easy to trigger crash: check if the project is destroyed in CTestFindJob::updateReady() and kill the job if this is the case. BUG: 329246 FIXED-IN: 5.6.1
-
Igor Kushnir authored
When a user exits KDevelop while a CTestFindJob is still working, the job is killed from RunController::cleanup() and its KJob parent calls deleteLater(). But the killed job can be still not destroyed after DUChain::shutdown() is called, which results in a crash if CTestFindJob::updateReady() is then invoked via Qt::QueuedConnection. Note that ~ParseJob() queues calls to CTestFindJob::updateReady(), which can then be invoked after DUChain::shutdown(), if ParseJob-s are running when the user exits KDevelop and no event loop is entered in the time between the ~ParseJob() and DUChain::shutdown() calls (sometimes the optional QCoreApplication::processEvents() call in BackgroundParser::waitForIdle() intervenes and prevents the crash). Core::cleanup() calls backgroundParser()->waitForIdle(), which ensures that all parse jobs finish, are destroyed and queue "updateReady" calls. BUG: 423651 FIXED-IN: 5.6.1
-
Igor Kushnir authored
KJob::percent(KJob *job, unsigned long percent) signal is public since https://commits.kde.org/kcoreaddons/c0b312a41f7fcb42ac6251a2d194c7799dfac723 (since KF 5.46). Simplify JobStatus implementation: * move slotPercent() from JobStatusPrivate to JobStatus for simplicity; * remove unused JobStatusPrivate::m_job data member. ulong => unsigned long in PatchReviewToolView::testJobPercent() because "ulong" is practically absent from KDevelop source code now. GIT_SILENT
-
Igor Kushnir authored
Let the more efficient loop below queue each set element instead of searching for each open document in the set gradually emptying it.
-
Igor Kushnir authored
When ParseProjectJob's forceUpdate argument is true, closed documents are parsed with TopDUContext::ForceUpdate feature flag. I think that not taking into account the forceUpdate argument when parsing open documents is an omission. Let us parse all documents with the TopDUContext::ForceUpdate feature flag when forceUpdate is true.
-
Igor Kushnir authored
GIT_SILENT
-
Igor Kushnir authored
This prevents unnecessary detaching. GIT_SILENT
-
Igor Kushnir authored
ParseProjectJob finishes normally when all its requests are satisfied by BackgroundParser, in which case there is nothing to revert. Both ProjectController and RunController abort parsing by killing the job. Apart from not doing unnecessary work when ParseProjectJob finishes normally, this commit prevents a hypothetical crash in case the BackgroundParser's destruction precedes a ParseProjectJob's destruction.
-
Igor Kushnir authored
ParseProjectJob::queueFilesToParse() removes the currently open documents that belong to the project from d->filesToParse. Therefore, when ParseProjectJob::updateReady() is invoked, the actual number of files to parse can be greater than d->filesToParse.size(). ParseProjectJob reverts all its requests in the destructor, so the few unaccounted-for closed documents could remain unparsed.
-
Igor Kushnir authored
Only RunController listens to ParseProjectJob::percent() signal (as it does to any registered job's percent() signal) in order to update total progress. Background Parser already reports parsing progress, so there is no need to emit ParseProjectJob::percent(), and so it makes sense to remove the empty updateProgress() function rather than implement it. GIT_SILENT
-
Igor Kushnir authored
Both the code and the documentation of ParseProjectJob are simplified by letting ProjectController call its parseAllProjectSources() function. GIT_SILENT
-
Igor Kushnir authored
KJob::finished() signal is guaranteed to be emitted from ~KJob() or earlier. RunController::finished() slot is connected to this signal and unregisters the job that emits it. GIT_SILENT
-
Igor Kushnir authored
Remove the now redundant deleting of the ParseProjectJob when its project is destroyed. ParseProjectJob objects are created in ProjectController::reparseProject(), which is called when the project is already fully open. So the project is guaranteed to be closed before it is destroyed. A Project is destroyed via deleteLater() after it is closed, so if the event loop is busy at the time, &IProject::destroyed can be emitted much later than IProjectController::projectClosing(). With this commit ParseProjectJob is killed earlier than it was destroyed without the commit. Early-return from ParseProjectJob::queueFilesToParse() not only when the job has been destroyed, but when it has been killed too. The earlier return not just avoids unnecessary work, but is essential during the application shutdown: prevents a crash by not accessing IndexedString after DUChain::shutdown(). Note that KJob::kill() calls deleteLater(), so a job can be destroyed a long time after it is killed if the event loop is busy, as it is at shutdown. ParseProjectJob is killed early in the shutdown process from RunController::cleanup() - before ProjectController::cleanup(), which would kill it otherwise, and (importantly to prevent the crash) before DUChain::shutdown(). Remove the shuttingDown() check from ParseProjectJob::start(), because this member function doesn't access globals on its own. The appropriate safety checks are now performed in the scheduled ParseProjectJob::queueFilesToParse(). Don't call deleteLater() in ParseProjectJob::doKill() just before returning true: rely on auto-delete KJob base class to call it. BUG: 427387 FIXED-IN: 5.6.1
-
Igor Kushnir authored
From KJob::start() documentation: Warning: Never implement any synchronous workload in this method. This method should just trigger the job startup, not do any work itself. It is expected to be non-blocking. When a user exits KDevelop in the ParseProjectJob::start()'s nested event loop, RunController may be destroyed in the time between `job->start();` and `checkState();` statements in RunController::registerJob(). The result is a segmentation fault in RunController::checkState(). BUG: 427386 FIXED-IN: 5.6.1
-
Igor Kushnir authored
Storing the QPointer-s indefinitely was a small memory leak. Eliminate a redundant QHash search in ProjectController::reparseProject(). Fix ProjectController::reparseProject() indentation.
-
Igor Kushnir authored
GIT_SILENT
-
Script Kiddy authored
In case of conflict in i18n, keep the version of the branch "ours" To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
-
David Redondo authored
-
David Redondo authored
If we do no unregister ourselves, KTextEditor will try calling into the destroyed notes provider.
-
- 30 Sep, 2020 3 commits
-
-
Igor Kushnir authored
GIT_SILENT
-
Igor Kushnir authored
This function has no observable effects other than imperceptibly slowing KDevelop down since 57e452e5, where its debug output was removed in favor of better-formatted debug output in MIDebugSession::handleDebuggerStateChange(). For some reason this no longer useful function was not removed in this commit. Now it only wastes CPU cycles and complicates understanding of the code. GIT_SILENT
-
Igor Kushnir authored
Deleting the QPointers at the beginning of ~CorePrivate() sets them to nullptr automatically. But even had the pointers remained non-nullptr, clearing them would be a waste, because the simple CorePrivate object containing them was destroyed right after the clear() calls. GIT_SILENT
-
- 23 Sep, 2020 1 commit
-
-
Igor Kushnir authored
-
- 22 Sep, 2020 1 commit
-
-
Igor Kushnir authored
When a user Execute-Launches an application a second time while the previously launched instance of this application is still running, the "Job Already Running" dialog appears with 3 buttons. If a user clicks the Cancel button, a NativeAppJob kills itself Quietly. This NativeAppJob belongs to an ExecuteCompositeJob, which is not notified when a subjob is killed Quietly. So the ExecuteCompositeJob keeps waiting for it to finish. When this waiting ExecuteCompositeJob is killed (e.g. via "Stop All" button or on KDevelop exit), it attempts to kill the subjob it believes is still running, but which in fact is long since destroyed. This usually causes a segmentation fault. Aleix Pol fixed a similar crash when the "Kill All Instances" button in the "Job Already Running" dialog is clicked in 8430d305. BUG: 399511, 416874 FIXED-IN: 5.6.1
-
- 18 Sep, 2020 2 commits
-
-
Friedrich W. H. Kossebau authored
GIT_SILENT
-
Script Kiddy authored
In case of conflict in i18n, keep the version of the branch "ours" To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
-
- 17 Sep, 2020 1 commit
-
-
Friedrich W. H. Kossebau authored
GIT_SILENT
-
- 10 Sep, 2020 2 commits
-
-
Carl Schwan authored
(cherry picked from commit 135d20ae + fix) GIT_SILENT
-
Friedrich W. H. Kossebau authored
GIT_SILENT
-
- 09 Sep, 2020 3 commits
-
-
Carl Schwan authored
-
Carl Schwan authored
-
Carl Schwan authored
-