GitLab

- Also changed bitwidth to uint16_t otherwise is too big by 1 byte
  to reduce the aligned size

QDBusServiceWatcher does not look for already registered
services. MIDebuggerPlugin does that now during setup.

Extend the test to verify the registration for both cases:
- start KDevelop, then start DrKonqi
- start DrKonqi (keep it running) then (re-)start KDevelop

Should hopefully fix the test failure on the CI

Previously we only supported this information for class declarations
and class members. But I find myself wanting to inspect this
information frequently for other types too, most notably type aliases
that instantiate a template.

Move the data from the ClassMemberDeclaration to the abstract type
and set it for all C++/C types we encounter that have that data.
Explicitly filter out function types, because we get strange data
there with libclang: sizeof 1, alignof 4? In reality one cannot
directly apply sizeof to a function anyways.

Also only unalias the types in the navigation context instead of
fully dereference them, as that would break the sizeof for pointers.

As this changes the layout of the on-disk DUChain data, we have to
bump our cache version number and trigger a full reparse.

Move the ProjectsGenerator to kdevplatform tests in order to make it accessible from other projects.

Use the now moved ProjectsGenerator to generate projects for testing in custom buildsystem plugin.
Clean up existing test-projects under git control.

The entry at Config::globalBuildDirIndexKey() is read only once - in
CMake::currentBuildDirIndex() - for backwards compatibility. This
function attempts to read an entry at Config::buildDirIndexKey() first.
Therefore, defaultConfigure() can safely write at this newer key,
assuming the current runtime does not change between the call to
defaultConfigure() and subsequent calls to CMake::currentBuildDirIndex()
(which is hopefully the case).

GIT_SILENT

6371b294 removed the single call to this
function in 2014. I don't know if the removal was intentional or a
mistake, but it doesn't matter now. The unused for 6 years configuration
migration function can be safely removed.

GIT_SILENT

The entry at Config::Specific::cmakeBinaryKey is read only once - in
CMake::currentCMakeExecutable() - for backwards compatibility. This
function uses the value at this key only if there is no value at
Config::Specific::cmakeExecutableKey. Therefore, defaultConfigure() can
safely write at this newer key.

GIT_SILENT

This header is currently included in one source file per
target/executable. Including it in multiple source files that belong to
a common target results in the following linker errors without `inline`:
  multiple definition of `projectPaths(QString const&, QString const&)';
  <two identical errors for defaultConfigure() and loadProject()>

GIT_SILENT

GIT_SILENT

Change the type of the global constants from QString to const char*
whenever possible to initialize them statically rather than dynamically.
In the few cases where const char* is unfeasible, replace the constants
with functions that return QString or QByteArray. Thus the possibility
of static initialization order fiasco and other issues with global
variables are eliminated.

These constants are used only as KConfigCore keys. Overloads of member
functions of KConfigCore classes, which take const QString& key, convert
the QString argument to const char*. So this change is beneficial to
performance.

Duplication in every translation unit of the UTF-8 and UTF-16 string
contents of a QStringLiteral and a QByteArrayLiteral in the new header
shouldn't be a problem, because this header is included only in one
source file and a test helper header, which in turn is included only in
test source files. So I haven't created cmakeconfiggroupkeys.cpp just to
de-inline the two *Literal-containing functions.

Remove the unused Config::Old::oldcmakeExecutableKey variable.

GIT_SILENT

The other instance may connect to the adaptor in the test after
our test plugin itself connected, leading to a failure. Ignore
those requests.

The initialization of these static data members is now static rather
than dynamic. Thus the possibility of static initialization order fiasco
and other issues with global variables are eliminated.

These strings are used only as KConfigGroup keys.
KConfigGroup::(read|write)Entry() overloads that take const QString& key
convert the QString argument to const char*. So this change is
beneficial to performance.

Move several constants from ExecutePlugin to its base class
IExecutePlugin in order to reuse them in debugger tests instead of
duplicating string literals.

GIT_SILENT

This commit completes 93244a8c and
a9afc574.

GIT_SILENT

GIT_SILENT

Getting rid of the variables eliminates the possibility of static
initialization order fiasco and other issues with global variables.

Move the strings' definitions from Execute(|Script)Plugin to
(Native|Script)AppConfigType classes, where they are also used, as the
former variables' names suggest.

GIT_SILENT

GIT_SILENT

GIT_SILENT

GIT_SILENT

GIT_SILENT

GIT_SILENT

The differences between the removed code and testhelper.cpp are minor
and inconsequential:
1) The extra parameter in compareData() `useRE` is false by default.
2) QTest::qFail() => QTest::qVerify() in compareData() should be fine.
3) GDB::DebugSession => MIDebugSession in waitForState() makes no
   difference because the `session` argument is used only to initialize
   a QPointer<MIDebugSession>.
4) 5'000 ms => 10'000 ms timeout interval in waitForState() shouldn't
   be a problem, because the test is slowed down only if it fails.
5) QPointer<GDB::DebugSession> => QPointer<MIDebugSession> in TestWaiter
   makes no difference, because only operator! is called on the
   `session` data member.

GIT_SILENT

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"

This change does not affect performance of
DUChainReferenceCounting-sensitive benchmarks.

Clang 8.0 rejects this standard-compliant code with the following error
messages:
  1) default member initializer for 'count' needed within definition of
  enclosing class 'DUChainReferenceCounting' outside of member unctions
  2) <same as (1) but with 'intervals' in place of 'count'>

This change does not affect performance of
DUChainReferenceCounting-sensitive benchmarks.

We explicitly don't build the debuggees with asan, but that then
makes this test fail as it would link against the asan-ified kdev
lib... So let's skip that in such configurations.

This is pretty nasty, but at least it fixes the memory leak...
We now manually delete the ctest suites and kill the jobs when
we remove a project or update its data.

In my case I get this warning at runtime:

```
Launch Configuration: "CTest" "No environment profile specified, looks
like a broken configuration, please check run configuration 'CTest'.
Using default environment profile."
```

And apparently no output job is created, leading to a crash.
Handle this gracefully.

Use QTest::addRow instead of qstrdup+newRow

In practice reference counting is enabled on any interval only in small
code fragments. shouldDoDUChainReferenceCounting() is called only in
assertions (which are disabled in Release mode) and in places that lock
a mutex if it returns true. The performance penalty of a wrong
Q_UNLIKELY prediction should be small in comparison to the mutex lock.

Comparison of the generated assembly code with and without Q_UNLIKELY
indicates that this keyword helps the compiler to order the code in a
way optimized for the more common path. Specifically, in the case of
~IndexedString() (in which DUChainReferenceCounting::shouldDo() is
inlined), Q_UNLIKELY eliminates a jump from the fast path: a `jne`
instruction replaces `je` and the fast-path code is moved up.

The following table compares performance of the previous, current and
considered alternative implementations in the affected benchmarks. The
numbers denote milliseconds per iteration. These numbers are minimums,
not averages. The 9031ee87 commit
message specifies the meaning of the columns in the table legend and the
methodology of benchmarking in the paragraph that starts with
"Each number in this and the older commit message's table".

version\benchmark       qhash   create  destroy shouldDo(-) shouldDo(+)
previous commit         0.95    143      75      70         171
this commit             0.84    141      74      70         247
redundant if            0.84    141      74      70         247
inline variable         0.84    141      74      70         247
static data member      0.93    143      79     141         353
extern variable         0.93    143      79     141         353
internal linkage        1.1     145     100     565         742
non-inline f-l static   1.1     146      96     565         742
std::any_of             0.85    142      74      70         565

Versions:
redundant if            - a more verbose Q_UNLIKELY optimization:
                        if (Q_UNLIKELY(count != 0)) {
                             for (std::size_t i = 0; i != count; ++i) {
                                ...
                          Milian suggested to move Q_UNLIKELY into the
                          loop exit condition to eliminate the redundant
                          `if` - after I benchmarked all alternative
                          implementations with the `if`. The benchmark
                          performance and the generated assembly code on
                          the fast path remained the same.
inline variable         - "redundant if", but with inline thread_local
                          variable in the header instead of instance()
static data member      - "redundant if", but with instance as a static
                          data member, not a static member function
extern variable         - "redundant if", but with extern thread_local
                          variable in the header instead of instance()
internal linkage        - "redundant if", but with static thread_local
                          variable in the cpp file instead of instance()
                          and shouldDoDUChainReferenceCounting() defined
                          in the cpp file
non-inline f-l static   - "redundant if", but with instance() defined in
                          the cpp file
std::any_of             - "redundant if", but with shouldDo()
                          reimplemented as follows:
    if (Q_LIKELY(count == 0)) return false;
    return std::any_of(intervals, intervals + count,
        [item](Interval interval) { return interval.contains(item); });

Now that the constructor of DUChainReferenceCounting is constexpr, the
performance of the inline variable is exactly the same as of the inline
function with a function-local static variable inside. I think we should
keep the current version, because it would probably be faster if the
constructor becomes non-constexpr in the future. In addition, lazy
initialization of the thread_local instance variable is preferable and
should be enforced, because most threads never use
DUChainReferenceCounting.

Eliminating dynamic initialization of the function-local thread_local
DUChainReferenceCounting variable substantially improves performance of
shouldDoDUChainReferenceCounting(). The only really useful code change
is assigning {} to intervals. Explicitly specifying `constexpr` and
`noexcept` does not affect performance, but I added them anyway to
indicate that these properties improve the performance of this class.
I have tried replacing `= {}` with `{}`, removing Q_DISABLE_COPY_MOVE
along with the user-declared default constructor, but these tweaks did
not affect performance.

The following table compares performance of the previous, current and a
considered alternative implementation in the affected benchmarks. The
numbers denote milliseconds per iteration. These numbers are minimums,
not averages. The 9031ee87 commit
message specifies the meaning of the columns in the table legend and the
methodology of benchmarking in the paragraph that starts with
"Each number in this and the older commit message's table".

version\benchmark       qhash   create  destroy shouldDo(-) shouldDo(+)
previous commit         1.2     149     107     106         196
this commit             0.95    143      75      70         171
std::any_of             1.3     149     107     318         388

"std::any_of" is the version at this commit, but with
DUChainReferenceCounting::shouldDo() reimplemented as follows:
    return std::any_of(intervals, intervals + count,
        [item](Interval interval) { return interval.contains(item); });

I have also benchmarked passing `interval` by const reference in the
"std::any_of" version, which did not substantially affect performance
(only BenchIndexedString::bench_destroy() became slower: 107 => 110).
In a currently predominant 64-bit architecture, sizeof(Interval) == 16,
so Interval is passed by value across DUChainReferenceCounting code as
per C++ Core Guidelines (For "in" parameters, pass cheaply-copied types
by value and others by reference to const).