- 30 Jan, 2023 1 commit
-
-
Friedrich W. H. Kossebau authored
GIT_SILENT
-
- 29 Jan, 2023 2 commits
-
-
Heiko Becker authored
(cherry picked from commit 4838a7d5)
-
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"
-
- 28 Jan, 2023 2 commits
-
-
Igor Kushnir authored
Average BenchQuickOpen::benchProjectFileFilter_setFilter results before and at this commit in milliseconds per iteration: Data row Before At 1000- 0.0018 0.0018 1000-bar 0.55 0.50 1000- 1 0.57 0.49 1000-f/b 0.47 0.41 10000- 0.0018 0.0018 10000-bar 5.8 5.3 10000- 1 5.5 4.7 10000-f/b 5.0 4.4
-
Script Kiddy authored
-
- 27 Jan, 2023 1 commit
-
-
Set the context object so that the lambda is not executed when the context object is deleted.
-
- 26 Jan, 2023 1 commit
-
-
Script Kiddy authored
-
- 25 Jan, 2023 1 commit
-
-
Script Kiddy authored
-
- 24 Jan, 2023 15 commits
-
-
Milian Wolff authored
GPU driver memory leaks are none of our concern.
-
8f253664 removed explicit support for this == 0. Though calling indexed() on nullptr might still work as expected in practice, calling a member function on a null pointer has always been undefined behavior. The documentation certainly shouldn't suggest triggering undefined behavior.
-
Milian Wolff authored
When the type is _not_ in a TypePtr, but e.g. handled via a unique_ptr, then this would potentially lead to double frees: ``` auto type = std::make_unique<SomeKDevelopType>(); type->indexed(); // creates TypePtr, destroys it, deletes the type // type now holds on to a dangling pointer // dtor of type would try to delete again, and crash ```
-
Milian Wolff authored
The bool-checks are not really needed and just complicate the code needlessly.
-
Milian Wolff authored
I.e. verify that the dynamicCast succeeds in debug builds
-
Milian Wolff authored
We get that implicitly, so it's redudant and can be removed to improve readability. Thanks to Igor Kushnir for the suggestion!
-
Milian Wolff authored
Only a few places in the ::equals implementations used this code. But it was not generic and actually unsafe to use elsewhere, note how e.g. the implementation for TypeAlias used the wrong WhichType. The implementation for ConstantIntegralType wasn't actually fast, it still always required an dynamic_cast. And in general, all other implementations where possibly broken for subclasses: When such a subclass would return a different WhichType, we would have always failed. Handling that would need a fallback to dynamic_cast, in which case we don't really gain anything code-generation wise. I doubt the speed impact is required - esp. considering this isn't used in practice anywhere so far... Just replace the few usages in assertions with dynamic_cast and get rid of fastCast code.
-
Milian Wolff authored
Use the non-static member functions instead, which is shorter and more in line with e.g. QSharedPointer usage too.
-
Milian Wolff authored
Cleanup usage accordingly, also note that we can rely on staticCast when we first check the whichType.
-
Milian Wolff authored
The compiler-default ones will call their QExplicitlySharedDataPointer counterparts internally and are thus good enough, no need to add another set that would be ambiguous in situations like: ``` StructureType::Ptr a; AbstractType::Ptr b; b = a; ```
-
Milian Wolff authored
This shouldn't be needed anymore, we certainly don't target GCC 4.0 anymore :)
-
Milian Wolff authored
Otherwise a .cpp file won't be parsed as such by default.
-
Script Kiddy authored
-
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
-
- 23 Jan, 2023 1 commit
-
-
Script Kiddy authored
-
- 22 Jan, 2023 4 commits
-
-
Igor Kushnir authored
Storing unneeded file paths and unnecessary CMake file classification wastes memory and CPU time.
-
Igor Kushnir authored
When project data is outdated right after configuring, KDevelop does not reconfigure the project to avoid a reload loop in case of a bug or some upstream CMake change. Project data can be outdated right after configuring if the user edits a source CMake file during a CMake configure or generate step. In this case reloading the project will bring the data up to date. Show a warning that asks the user to do just that. The user can finish editing source CMake files, reload the project, and the reminding warning will disappear automatically. If a reload loop occurs for some reason, the user will eventually cease reloading and hopefully report a bug. I plan to implement the added TODO together with future project reloading fixes. CCBUG: 460450
-
Igor Kushnir authored
The current algorithm is simple: consider project data outdated if the API reply index file was last modified before a possibly generated source CMake file. Unfortunately this algorithm is unreliable: 1) does not detect source CMake file modifications made during a CMake configure or generate step; 2) ignores CMakeCache.txt modifications. Improvements in this commit: 1. Consider project data invalid if KDevelop's CMake file API client query file does not exist. KDevelop never removes this file. The absence of the client query file can mean that it has never been created, in which case there can be no API reply; or it was removed during a prune job, which should have removed the API reply as well; or it was removed for some other reason, possibly an error. 2. Consider project data outdated if the API reply index file was last modified before the API client query file. This means that a CMake generate step was canceled - probably because of some error. 3. Consider project data outdated if the API reply index file was last modified before CMakeCache.txt. This can mean that the user modified CMakeCache.txt manually but did not run cmake afterwards, or run only a CMake configure step, but not a CMake generate step, which updates the API reply. 4. Consider project data outdated if the API client query file was last modified before a non-generated source CMake file. A non-generated source CMake file can be last modified between the API client query and reply index files for two reasons: 1) the user edited a source CMake file during a CMake configure or generate step, in which case project data is out of date; 2) the user edited a source CMake file, then run CMake configure and generate steps outside of KDevelop, in which case project data is up to date. Since KDevelop cannot know the true reason, it should err on the side of caution and consider project data outdated in this case. The user is not supposed to edit generated CMake files, so ignoring their modifications is safe enough. Generated CMake files can be modified during a CMake configure step, which occurs after KDevelop creates the API client query file. 5. Optimize by finishing CMake::FileApi::ImportJob as soon as it detects that project data is out of date, if ChooseCMakeInterfaceJob::tryDirectImport(), which discards outdated data, creates the job. Ignoring modifications to generated CMake files brings outdated project data detection algorithm closer to the algorithm in CMakeManager::integrateData(), which decides whether to reload a project when a file is changed. The remaining and just introduced inconsistencies between these two algorithms: 1. Modifications to external source CMake files make project data outdated, but such modifications are not tracked. Watching each individual external CMake file can be costly and cause issues elsewhere if a watched item count limit is reached. QFileSystemWatcher's documentation warns: The act of monitoring files and directories for modifications consumes system resources. This implies there is a limit to the number of files and directories your process can monitor simultaneously. External source CMake files can be modified when the user updates an external dependency of a project opened in KDevelop, or when system updates are installed. The user should be aware of both events and can reload or reopen the project to reconfigure it, or restart KDevelop. 2. Modifications to CMakeCache.txt make project data outdated, but such modifications are not tracked. Reloading the project after each CMakeCache.txt change is risky. CMakeCache.txt can be modified during a CMake configure step. If this CMake configure step occurs outside of KDevelop, concurrent CMake configuration runs can corrupt build data. Even if the CMake configure step that modifies CMakeCache.txt runs inside KDevelop, reloading the project risks creating a reload loop. When the user edits a source CMake file during a CMake configure or generate step, KDevelop prints a kdevelop.plugins.cmake.debug message: "the project is being reloaded, aborting reload!" but does not reconfigure the project automatically for now. But at least with this commit when KDevelop is restarted, it detects that project data is out of date and reconfigures the project. CCBUG: 460450
-
Script Kiddy authored
-
- 21 Jan, 2023 9 commits
-
-
Igor Kushnir authored
DebugController::areaChanged is connected to Sublime::MainWindow::areaChanged each time a debug session is started. These multiple connections result in repeated calls to m_currentSession->stopDebugger(). Usually the first stopDebugger() call clears the command queue, sets s_shuttingDown debugger state on and queues a single command: GdbExit, which is then immediately executed. In this scenario the additional stopDebugger() calls have no effect, because they clear the already empty command queue, notice that the s_shuttingDown debugger state is on and return. However, if the current debug session was created by attaching to a process with GDB, the first stopDebugger() call queues two commands: TargetDetach and GdbExit. The TargetDetach command is executed, but the GdbExit command remains pending. The next (redundant) stopDebugger() call clears the command queue, that is removes/cancels the pending GdbExit command, and returns. The gdb process does not exit then. The fallback gdb-killing lambda, which runs after a 5-second timeout, finds that s_programExited debugger state is on and does nothing. As a result, the gdb process remains running, the debug session and the MIAttachProcessJob remain alive. Starting another debugging asks the user to abort the invisible currently running debug session. But the session is not actually aborted because it is stuck with an unexpected debugger state: s_programExited|s_attached|s_shuttingDown. In this way it is possible to create an unlimited number of gdb processes, debug sessions and MIAttachProcessJob objects, which are destroyed only on KDevelop exit.
-
Igor Kushnir authored
The constructor of a MI debug job creates a debug session. When the Select Core File dialog is rejected, MIExamineCoreJob doesn't call MIDebugSession::examineCoreFile() and finishes. The debug session is not destroyed and the Debug area remains active in KDevelop then. Calling MIDebugSession::stopDebugger() finishes the debug session and lets DebugController destroy it. This function explicitly and correctly handles stopping debugger when it is not started.
-
Igor Kushnir authored
-
Igor Kushnir authored
The constructor of a MI debug job creates a debug session. When the configured launch executable or its arguments are invalid, MIDebugJob doesn't call MIDebugSession::startDebugging() and finishes with an error. The debug session is not destroyed and the Debug area remains active in KDevelop then. Calling MIDebugSession::stopDebugger() finishes the debug session and lets DebugController destroy it. This function explicitly and correctly handles stopping debugger when it is not started. BUG: 369313 FIXED-IN: 5.11.230400
-
Igor Kushnir authored
The error codes help to classify error messages that appear in KDevelop's output. For example: kdevplatform.util: JOB ERROR: 331 "A shell meta character was included in the executable for the launch configuration 'test-project', this is not supported currently. Aborting start."
-
Igor Kushnir authored
-
Igor Kushnir authored
When the external terminal emulator command is invalid, debugging an application fails to start with the error message "<invalid command> is incorrect terminal name". But then the debug session is not destroyed, commands in the command queue run and uselessly configure GDB, the Debug area remains active in KDevelop.
-
Igor Kushnir authored
User-requested debugging of an application fails to start in case of an STTY error, so the Information message type is not suitable.
-
Script Kiddy authored
-
- 20 Jan, 2023 3 commits
-
-
Igor Kushnir authored
DebugController is responsible for destroying debug sessions in KDevelop. Register test debug sessions with DebugController to properly clean them up. The following note is present in IDebugSession::breakpointController(), IDebugSession::variableController() and IDebugSession::frameStackModel() documentations: @note Implementations must ensure that a <(controller|model)> always exists (even if it is a dummy stub implementation that does nothing), and that it does not change during the lifetime of a session. DebugController::addSession() asserts that these functions return non-null pointers. Therefore TestDebugSession() creates these objects now. Pure virtual MIDebugSession::breakpointController() overrides IDebugSession::breakpointController() and returns MIBreakpointController, which inherits IBreakpointController. TestBreakpointController inherits IBreakpointController, not MIBreakpointController. Thus TestDebugSession has to create non-dummy MIBreakpointController rather than dummy TestBreakpointController. This commit is a proper debug session leak fix that replaces recently reverted fix in a wrong place 1256df11.
-
Igor Kushnir authored
The constructor of a MI debug job creates a debug session. A debug session emits finished() and is destroyed when it finishes. A MI debug job finishes normally when its debug session emits finished(). When a MI debug job is killed, it calls MIDebugSession::stopDebugger(), which finishes the debug session. However, when a MI debug job is destroyed before it starts running, the debug session is leaked. A job should never leak resources, no matter when or how it is destroyed. If a MIDebugJob has a dependency, GdbLauncher::start() adds the MIDebugJob as the second subjob of an ExecuteCompositeJob. If an ExecuteCompositeJob is configured to abort on error (which is the default and almost always the case), when a subjob finishes with an error, the remaining subjobs are never started, the composite job finishes and is soon destroyed. The remaining subjobs are owned by the composite job and are destroyed along with it. This scenario happens when a MIDebugJob job depends on a build job, and the build job fails, e.g. because of a syntax error in the program. Without this commit, the job's debug session is not destroyed and the Debug area remains active in KDevelop then. ExecuteCompositeJob::doKill() does not kill the remaining subjobs if killing a subjob fails. Since ExecuteCompositeJob is a parent of its subjobs, the not-killed subjobs are eventually destroyed along with it. Furthermore, I believe that not-started subjobs should always be simply destroyed rather than killed, and plan to implement this change soon. BUG: 394104 FIXED-IN: 5.11.230400
-
Igor Kushnir authored
The expanded output helps to understand debug job and debug session lifetime patterns.
-