GIT_SILENT

(cherry picked from commit 4838a7d5)

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"

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

Emilio Bova authored Jan 27, 2023 and Milian Wolff committed Jan 27, 2023

Set the context object so that the lambda is not executed when
the context object is deleted.

GPU driver memory leaks are none of our concern.

Igor Kushnir authored Jan 22, 2023 and Milian Wolff committed Jan 24, 2023

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.

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
```

The bool-checks are not really needed and just complicate the
code needlessly.

I.e. verify that the dynamicCast succeeds in debug builds

We get that implicitly, so it's redudant and can be removed to
improve readability.

Thanks to Igor Kushnir for the suggestion!

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.

Use the non-static member functions instead, which is shorter
and more in line with e.g. QSharedPointer usage too.

Cleanup usage accordingly, also note that we can rely on staticCast
when we first check the whichType.

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;
```

This shouldn't be needed anymore, we certainly don't target GCC 4.0
anymore :)

Otherwise a .cpp file won't be parsed as such by default.

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"

Storing unneeded file paths and unnecessary CMake file classification
wastes memory and CPU time.

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

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

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.

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.

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

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."

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.

User-requested debugging of an application fails to start in case of
an STTY error, so the Information message type is not suitable.

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.

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

The expanded output helps to understand debug job and debug session
lifetime patterns.