Inside the body of a function template, clang reports a different cursor
type for operators in some cases. Make sure we don't mistake such
operator< or operator> as opening or closing a template, respectively.
Fixes: QTCREATORBUG-25596
Change-Id: Ifc357e199ea13e44ac501613639e667c333d48e3
Reviewed-by: David Schulz <david.schulz@qt.io>
We need to take into account that the ">>" in constructs such as
std::vector<std::pair<int, int>> is only one token on the clang side.
Change-Id: I90f002ca56f236032f6d39c338593a2ff7590061
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: David Schulz <david.schulz@qt.io>
That is, show which ":" belongs to which "?" when the cursor is on one
of them.
Fixes: QTCREATORBUG-1410
Change-Id: Ie19360b3dfc82d92c264d99a5aa1864eda66e5c8
Reviewed-by: David Schulz <david.schulz@qt.io>
... in template declarations and instantiations.
Fixes: QTCREATORBUG-16799
Change-Id: I82bc6411ca980ecbe2a6c70ae37580166a4b89e9
Reviewed-by: David Schulz <david.schulz@qt.io>
... in cases where it appears that clang_annotateTokens() did not do
what we wanted.
Fixes: QTCREATORBUG-21522
Change-Id: I272061cb6c4b51a5d779ace5b4e06912c0a386e5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
These were falsely categorized as string literals. No one ever noticed,
because highlighting information for string literals was ignored until
baf25e4cdb.
Change-Id: Ib59fde04359aecb6da3995de1a9febbbf41b12c8
Reviewed-by: David Schulz <david.schulz@qt.io>
These are reported by libclang as "unexposed declarations".
Fixes: QTCREATORBUG-24769
Change-Id: I7a74b707f4203becabaa74b90758a7b396ee23bd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
We cannot assume that a Q_PROPERTY name is on the same line as the
keyword.
Fixes: QTCREATORBUG-24746
Change-Id: Ic2e02291e24c1abbaf72881b540a26c82899cb2c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
We now get the resource path from creator. The -fPIC case is working now
too.
Change-Id: Id191e89e6d46706748d50440038a06a349972cc9
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Static members have a variable declaration kind so
we need to check their access specifiers in order to
provide proper information about tokens.
Fixes: QTCREATORBUG-22082
Change-Id: If455174bd346398a2df3499fa6cf1ea2b4e26965
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
This fixes the basic case, but e.g. captures with initializers, e.g.
[foo=bar] are not properly reported by libclang and thus "bar" is still
not highlighted for this case.
Task-number: QTCREATORBUG-15271
Change-Id: I1a2d465f71b0ae1a0406ef9e77d88898e8637958
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
The are not any more shown but they are still not shown for constructor
arguments because libClang is providing the wrong argument count.
Task-number: QTCREATORBUG-21543
Change-Id: If9b6140ed4b2dedf71bd94aae0a97669cdd04e67
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
...with an extra parse.
Previously, the creation of an e.g. "Qt Widgets Application" from the
wizard could show code model errors in mainwindow.cpp. Depending on
timing issues, the first error is either
1. 'ui_mainwindow.h' file not found (QTCREATORBUG-15187)
The parse happened before the in-memory ui_mainwindow.h was
generated by uic. The file system watcher can't help here as the
#include was not resolved successfully. And libclang's reparse does
not handle this case (it would need to remember all failed #include
stats...).
==> Detect this case with the help of the include paths and trigger
a full parse.
2. or: allocation of incomplete type... (QTCREATORBUG-15187)
The parse happened after the generation of the in-memory
ui_mainwindow.h, but before the clangbackend received the unsaved
file.
==> Fix this by also writing the content of the unsaved file to our
behind-the-scenes-created ui_mainwindow.h.
Fixes: QTCREATORBUG-15187
Fixes: QTCREATORBUG-17002
Change-Id: I4f3a81adaa3d604746977a402c29f83fbc5b0e44
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
...as it is not needed. Just provide the compilation arguments as part
of the Document.
As a side effect, re-initializing the backend after a crash is cheaper
and will not freeze the UI anymore (referenced bug).
Task-number: QTCREATORBUG-21097
Change-Id: I866e25ef1fd5e4d318df16612a7564469e6baa11
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Currently only operators have their own style but not
punctuation tokens. Make possible to highlight both.
Task-number: QTCREATORBUG-20666
Change-Id: I9533e0f1bef65b86c4e4f5c9756571103584124b
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
This change limits the set of tokens that fall under
Token::isOperator(). That allows cpphighlighter.cpp to
distinguish operator tokens from punctuator tokens
(without changing any logic in cpphighlighter.cpp).
This change moves punctuators from "Operator"
to the "Text" style category where they belong.
Punctuators are not operators. Punctuators are
dumb text tokens.
Why don't we let the clang backend alone separate
these tokens for us?
1. Clang is slow on big files. Sometimes the
highlighting dictated by clang is painted _seconds_
after cpphighlighter.cpp runs. CppHighlighter is way
faster so we use it to "prepaint" code while clang is
busy in the background.
2. Secondly, clang cannot yet handle all operator types.
In particular, none if its "operator cursors"
CXCursor_UnaryOperator:
CXCursor_BinaryOperator:
CXCursor_CompoundAssignOperator:
CXCursor_ConditionalOperator:
includes the -> and . operators.
We still need CppHighlighter to paint those tokens.
However, once clang has finished processing the file some
operator tokens will be repainted. We need clang to get
all operators' semantics. In particular, we need clang to
tell us if < is a "smaller than"-operator or part of a
template parameter like set<int>.
Task-number: QTCREATORBUG-19659
Change-Id: I952cb58f7c79134b3281e2a8221425cc1d0ad263
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Color types and enable Ctrl+click for the functions
and types inside SIGNAL/SLOT macros.
Change-Id: Ic1c0b7372fe9a73c5607b1973d75a6656c75ef0e
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
We used to style overloaded operators in the same way
as C++'s built-in operators. There was no way to tell
if a + token would call a operator+() function or not.
Now, if an operator is overloaded (redefined),
we give it the "Overloaded Operator"-mixin so users
can style it differently.
Note: Calls to overloaded 'new' and 'delete' are not
highlighted by "Overloaded Operator". This is because
clang today always maps these to CXCursor_CXXNewExpr
and CXCursor_CXXDeleteExpr with cursor.spelling == ""
(empty string). So there is no (?) quick way for us
to tell if a new/delete-token was overloaded or not.
After follow-ups, follow symbol will work for operator
overload usages in current translation unit.
Commit is appended by Ivan Donchevskii.
Task-number: QTCREATORBUG-19659
Change-Id: I157855d482a61ad2059642a1ee982089fcb7d312
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Build the tree in only one loop.
clangbackend generates tokens almost as fast as it
did before (about 10% slower in general).
Broken documents are more affected and take much more
time (about 300%) but it's better to have this time spent
on backend side then in QtC itself.
Task-number: QTCREATORBUG-20205
Change-Id: I34c58bca30c4494005a029abd82c7e612ecd6fb9
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Add extra data to Keyword tokens.
Does not affect highlighting.
Change-Id: I206499ea35ee4ece5fe442665c904090cf5d90fc
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
The patch is mostly mechanical, but contains also a few spurious changes
from values references for some local variables, foreach -> ranged for
etc that I coulnd't resist.
Change-Id: I58f0bd972546895eb318607cbfbd7ac35caf3f23
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
Transform Q_PROPERTY into unique AST node.
Mark different parts with types and search for parent
in FullTokenInfos.
Change-Id: Iaa1ec0c73d34773edf5605d3682bd6a290d195de
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
