Unfortunately, clangd refuses to rename macros and namespaces.
Fall back to our old two-stage "find + replace" approach for macros
(which clangd can find just fine) and employ the built-in code model for
namespaces (as they don't get indexed at all by clangd).
Change-Id: I08b1088ff4de9220427e089ef0700dbf2a944081
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
We highlight concepts as types for now, as it's a pretty good fit. We can
always introduce a dedicated concept highlighting type later if there is
demand.
Task-number: QTCREATORBUG-28887
Change-Id: I405db5ca4351efd565b968e765fe8bca976a2800
Reviewed-by: David Schulz <david.schulz@qt.io>
As of a3af941adf, the built-in highlighter
can properly handle multi-line raw string literals, so we don't need to
abuse the semantic highlighter for this anymore.
Fixes: QTCREATORBUG-26693
Fixes: QTCREATORBUG-28284
Change-Id: If644767dfa8a97294e84a541eea44143e8d1bb88
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: David Schulz <david.schulz@qt.io>
We try to locate the old symbol name in the generated ui header and
rename the symbol in the background.
Task-number: QTCREATORBUG-1179
Change-Id: Iaf68e3922cd728cbc87d0dc97125e34b8bdaa6be
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: David Schulz <david.schulz@qt.io>
Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
We now get a semantic token "operator" from clangd;
see https://reviews.llvm.org/D136594.
As a side effect, this results in the following subtle changes in what
exactly gets highlighted, both of which make sense:
- The type part of a conversion operator is now highlighted as
a type, not an operator.
- We no longer add special highlighting for the brackets in
operator new[] and operator delete[].
Change-Id: Ic149487496768762728a712c9fbcde5c9516529c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: David Schulz <david.schulz@qt.io>
Note that especially in C++, there can be a lot of false positives,
especially in template-heavy code bases. We filter out the most notorious
offenders, namely:
- templates themselves
- constructors and destructors
- *begin() and *end()
- qHash()
- main()
Since the code model does not know about symbol visibility, the
functionality is quite useless for libraries, unless you want to check
your test coverage.
The procedure is rather slow, but that shouldn't matter so much, as it's
something you'll only run "once in a while".
Fixes: QTCREATORBUG-6772
Change-Id: If00a537b760a9b0babdda6c848133715c3240155
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
In particular, in a variable definition, the (invisible) reference to the
constructor is *not* a declaration (but an implicit call).
Change-Id: Ic1f29a4da360959e81ec536efbf1175924ea34d7
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: David Schulz <david.schulz@qt.io>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace.
Task-number: QTBUG-99313
Change-Id: I88edd91395849574436299b8badda21bb93bea39
Reviewed-by: hjk <hjk@qt.io>
Making use of LSP's "Go To Type Definition".
Just the backend for now, UI to follow.
Change-Id: Id73b2cf701eab03913477f6d4d3093e257e80dbd
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
... for a document.
This was only ever implemented for the built-in code model.
Fixes: QTCREATORBUG-20423
Change-Id: Ia99d0136e9995a5626058ad06173ea077be024d8
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: David Schulz <david.schulz@qt.io>
And instead of qgetenv.
Takes Qt Creator's setting at "Environment > System > Environment" into
account, which makes it easier on some platforms to set them (e.g.
macOS), can be configured differently in different settings paths, and
potentially can be changed at runtime (depending on usage).
Change-Id: I7678b8e429b5eff79f87eb637f6f2131be43d904
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This is a local variable, not a macro.
Also take into account the new upstream support for this (see
https://reviews.llvm.org/D131175), which required us to fix our
assumption that "static" always means "static member".
Change-Id: I69f3c98737571cbd55f9c64c02292426acb6031b
Reviewed-by: David Schulz <david.schulz@qt.io>
Macros are used like identifiers; there is no reason why they should need
to have the same highlighting as a preprocessor directive.
Fixes: QTCREATORBUG-23548
Change-Id: I186befc06ccb36a00451fd707c41e3687a84af14
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: David Schulz <david.schulz@qt.io>
... in output argument highlighting.
If there is not enough information for clang to determine the const-ness
of the argument passing (as it can happen in templates), do not report
an output argument.
Change-Id: I8d0143042f02ac44d8d971398014828cff14697f
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: David Schulz <david.schulz@qt.io>
We need to relax the range check: In expressions such as x.y->z, the
second argument for the operator->call is x.y, not just y.
Fixes: QTCREATORBUG-27352
Change-Id: Ida542c11c129630f0a1d301508ec5f8076eb9902
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: David Schulz <david.schulz@qt.io>
... as output arguments with clangd.
We might want to do so in the future, but right now it's not intended.
Task-number: QTCREATORBUG-27111
Change-Id: Ie6941f18943a1d6942901c526c62999cba6c1125
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: David Schulz <david.schulz@qt.io>
... with clangd.
As with operator++ etc, it's immediately obvious to a developer which
arguments are modified.
Change-Id: Ia2b15d5eef7848b7ed284f8d544f039fe2927292
Reviewed-by: David Schulz <david.schulz@qt.io>
If we open a file that does not belong to a currently open project, there
is a good chance that the current project's parse context is a better fit
for the file than the fallback client's.
Fixes: QTCREATORBUG-26697
Change-Id: I6c17e275b047602c51364f3203b3f0a3e74a49fc
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: David Schulz <david.schulz@qt.io>
