Before we only supported UL and ULL.
And add tests for all variants of allowed integer suffixes.
Fixes: QTCREATORBUG-25604
Change-Id: Id92f371d2effa7456d2d50891a6c29810c5c4c75
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Otherwise, we trip over uses of operators from the standard
library such as std::chrono's operator"" ms(), potentially breaking
basic code navigation.
Amends 425811291d.
Fixes: QTCREATORBUG-24067
Change-Id: I3b2863ce88ee3787414e7a1acdf25f368041cdb4
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
C++14 supports the use of single quotes inserted between integer digits
as a separator. Updates the built-in C++ code model to recognize such
quotes. This fixes highlighting and indentation issues.
Change-Id: Ic35ce93060b96700a11d108dce1f3cf6c4543632
Fixes: QTCREATORBUG-14939
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Based on Tobias Hunger's work from a few months ago.
The CMake configuration needs libclang and Qt paths specified as
CMAKE_PREFIX_PATH.
Auto tests are run with "ctest". At the moment the pass rate is 87%.
Change-Id: Iba98e39bf22077d52706dce6c85986be67a6eab0
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
While parsing a document Bind::asStringLiteral() Token::spell() was
called for a raw string literal token with a Token::literal nullptr.
This is due scanRawStringLiteral() not properly aborting for
invalid/incomplete code and that the code paths handling
multi-line-raw-strings were not limited to the highlighting case.
Address both cases.
Task-number: QTCREATORBUG-18941
Change-Id: I489d288ccbd7b59be396dada846613ff555436cf
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
With the built-in model, which affects basic highlighting.
Task-number: QTCREATORBUG-17720
Change-Id: I7369d7288d9c2c8e5ef36fc27549121014527e58
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
In some (legacy) C files, new and delete may be used for regular identifier.
There are some limitations:
* Header files have no 'implicit' type, and may be parsed as C++ or ObjC depending on the
other files in the project.
* QMakeProject use a single ProjectPart for C and C++ files, so there will still be the issue.
Change-Id: Iec11687b35f7ccf1e7c0d091b143ae90d950e440
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
...with MSVC2013.
tst_lexer.cpp(406) : error C2398: Element '1': conversion from
'CPlusPlus::Kind' to 'unsigned int' requires a narrowing conversion
Change-Id: I1c9415cb02d2f0fa85d48a1abbc688d8f53b5b43
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The current code always ends up setting the token to T_GREATER_GREATER.
Change-Id: If75ff1f5bccffd5918ec2bf491724cd0981220ae
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
According to section 2.5 from the standard:
""" If the input stream has been parsed into preprocessing tokens up to
a given character: ... Otherwise, if the next three characters are <::
and the subsequent character is neither : nor >, the < is treated as a
preprocessor token by itself and not as the first character of the
alternative token <:. """
Change-Id: Ib9cdac61e3c2243d1bc1d4471a09ae6bd839fdda
Task-number: QTCREATORBUG-13253
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
Trigraphs must only be parsed before/during preprocessing. The preprocessor
will now replace trigraphs with their standard form, and re-lexing in
TranslationUnit will not try to parse any trigraph.
Also added a few missing trigraphs: ??=, ??', ??! and ??-.
Task-number: QTCREATORBUG-13253
Change-Id: I1723ed53b00090b878c22b83b7e963b647b65f72
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
MSVC2010 supports all combinations of upper- and lowercase U/I.
Task-number: QTCREATORBUG-15554
Change-Id: I0106e6b5038a62aebe5a6c1eb0467d693befb4b0
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
1. Extends lexer so digit or string can be followed by underscore '_' and
alphanumeric defining literal.
2. Extends parser so it accepts operator"" _abc(...) user-defined literal
definition.
3. Adds Token::Flags.userDefinedLiteral bool flag field representing if token
carries user-defined literal.
4. Adds C++11 auto tests case with: 12_km, 0.5_Pa, 'c'_X, "abd"_L, u"xyz"_M
5. All optional suffix scanning methods now return boolean if the suffix was
found.
6. Adds C++ Lexer tests for user-defined literals with C++11 feature enabled.
This change however does not make QtCreator understand user-defined literal
semantics, e.g. properly resolve type when applying custom literal operator.
Change-Id: I30e62f025ec9fb11c39261985ea4d772b1a80949
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
Separate the messy pp-number parsing from the numeric literal parsing.
The C/C++ preprocessor makes a grown man cry, but at least we have
"proper" literal parsing when we want it, including C++1y binary
literals.
Next step is digit separators (n3781).
Change-Id: Ia069eef454ed5c056f77694a5b8a595d0b76adc4
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
The Lexer can handle it now.
Task-number: QTCREATORBUG-7356
Change-Id: I8c4b03a247656e013d44c3cedca4835e133d4036
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
This will save us toLatin1() conversations in CppTools (which already
holds UTF-8 encoded QByteArrays) and thus loss of information (see
QTCREATORBUG-7356). It also gives us support for non-latin1 identifiers.
API-wise the following functions are added to Token. In follow-up
patches these will become handy in combination with QStrings.
utf16chars() - aequivalent of bytes()
utf16charsBegin() - aequivalent of bytesBegin()
utf16charsEnd() - aequivalent of bytesEnd()
Next steps:
* Adapt functions from TranslationUnit. They should work with utf16
chars in order to calculate lines and columns correctly also for
UTF-8 multi-byte code points.
* Adapt the higher level clients:
* Cpp{Tools,Editor} should expect UTF-8 encoded Literals.
* Cpp{Tools,Editor}: When dealing with identifiers on the
QString/QTextDocument layer, code points
represendet by two QChars need to be respected, too.
* Ensure Macro::offsets() and Document::MacroUse::{begin,end}() report
offsets usable in CppEditor/CppTools.
Addresses QTCREATORBUG-7356.
Change-Id: I0791b5236be8215d24fb8e38a1f7cb0d279454c0
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Also fix false positive line continuation on blank line
e.g.
"foo \
bar"
Change-Id: Ic6d345a4b578c955411d119b8438c8dc5065c072
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
spell() crashes if identifier is not properly created
Change-Id: I1c3949c3fed2282d893914fa2922f6c281d1f8cd
Reviewed-by: Przemyslaw Gorszkowski <pgorszkowski@gmail.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
...to a more generic name since it is not any more limited to doxygen.
Change-Id: I0fca5dab9b5ab8850b2cfba5758b51f0451c199d
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
The trigraph sequence somehow confused qmake. The moc file was not
generated.
Change-Id: I4016947b5c8efa350d1813737651143d8687d299
Reviewed-by: hjk <hjk121@nokiamail.com>
Almost most useful feature ever.
Task-number: QTCREATORBUG-2474
Change-Id: If1ad661fab58ffb4a0b9ddb8ba771f2fde3b54ec
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
Note: Since not all autotests are able to run from an installed location,
we need to be able to start them from the build directory, which
in turn forces us to set a destination directory for libraries and plugins,
so they will be found at run-time.
Change-Id: Idcf7e1333dfa6e9dbf745391b78c035f842ccc5a
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
... and adjust INCLUDEPATH accordingly.
while i'm at messing with include statements, also re-order the include
blocks according to policy and sort them within bigger blocks.
Change-Id: I7762abfd7c4ecf59432b99db2f424e4fa25733a5
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Now everything following '///' or '//!' is a doxygen comment.
This simplification fixes also the bug ('\n' was considered as part of
the doxygen comment and led to strange highlighting).
Task-number: QTCREATORBUG-8921
Change-Id: I6dae3b80ec11400f2f623897257782a80860a7f3
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
