It looks very much as though the original author simply forgot to add
that return statement.
Fixes: QTCREATORBUG-23881
Change-Id: Ie93d2451bf1b491d01137285f983d657133c81c3
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Use the original offset only in the one place where it is relevant.
This amends commit 8eac3fba80.
Fixes: QTCREATORBUG-24221
Change-Id: Idcfc5ecc8a76c875c4f2ca5890d0ba95ce52a6e9
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
At some point in the preprocessing stage, some tokens get "squeezed", so
their associated string no longer refers to the document content, but
only to their own symbol. However, there is at least one context that
operated under the assumption that the token's offset still pointed into
the "global" string. As the token's offset is zero after parsing, this
lead to the same piece of code being preprocessed in an infinite loop.
Fixes: QTCREATORBUG-19525
Change-Id: I231ba51811cfa0b5c6dfe7f75fe0384472252c6f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Recently tons of warnings show up for presumably "problematic"
singned <-> unsigned and size conversions.
The Qt side uses 'int', and that's the biggest 'integration surface'
for us, so instead of establishing some internal boundary between
signed and unsigned areas, push that boundary out of creator core code,
and use 'int' everywhere.
Because it reduces friction further, also do it in libcplusplus.
Change-Id: I84f3b79852c8029713e7ea6f133ffb9ef7030a70
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Arguments of funstion-like macro may contain the name of this
macro. The attempt to expand it results into infinite recursion.
Patch solves that by saving the macro name until the arguments
are collected to determine that it should not be expanded.
Fixes: QTCREATORBUG-21642
Change-Id: Iafb404ecd3959a2f1011c12c1c3f1c0c54ed3547
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
Qt Creator almost hangs and consumes a lot of memory if that happens.
Just ignore such cases in preprocessor.
Task-number: QTCREATORBUG-18995
Change-Id: Ib81cc18738696b02f98e5064d06c719a44ebdaa3
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
The m_parserFuture.cancel() in ~BuiltinEditorDocumentProcessor() did not
cancel anything. Thus, closing a document while the parser was running
led to a blocking UI thread.
Now it cancels at the next include directive it encounters.
Change-Id: I092fddbbd747e0bc95265b6e9b4fcc26b3f76cb3
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
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>
It crashed in some places on our code-base due to the so-called "static
initialization order fiasco".
As a solution, it turns the variable into a function. This shouldn't have
a penalty due to QStringLiteral.
Change-Id: I9f8a955afdff878dc2f0db16fec861d81250c243
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
operator bool() is a trap, but with explicit it's far safer,
and we can use that now.
Change-Id: I4e58631c94e87c00256c3ab3cff4fd2c5f632713
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
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>
See [global.names] (17.6.4.3.2 in the C++11 spec.)
Change-Id: I8434496dbe392b52d339d5f17cfaeee8dbd88995
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
This caused displaced highlighting of macro uses after #if constructs.
MacroUse::utf16charBegin() was based on the last "continuation token",
which was wrong.
Change-Id: I89983d82fcf804ba853c04a59a7533c489785d05
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
In most cases we need to work with the utf16 indices. Only in
cppfindreferences the byte interface is still needed since there we read
in files and work on a QByteArray to save memory.
Change-Id: I6ef6a93fc1875a8c9a305c075d51a9ca034c41bb
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
The Lexer can handle it now.
Task-number: QTCREATORBUG-7356
Change-Id: I8c4b03a247656e013d44c3cedca4835e133d4036
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
This will avoid confusion when later more length and indices methods are
added.
In Token:
length() --> bytes()
begin() --> bytesBegin()
end() --> bytesEnd()
Change-Id: I244c69b022e239ee762b4114559e707f93ff344f
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
They are already inlined. Now it's easier to find read-only accesses.
Change-Id: I9aaeca3bc5860e3a20a536a2484925e4334c005f
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
baseLine is used for generating new tokens, which are
later added m_state.m_lineRef - 1 again
Change-Id: I33928a90988e8d4c317ae460647f16f87da5b155
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
* If the macro is defined before, track its reference
* Synchronize environment line before calling remove, which
currently sets incorrect line
* Set macro offset
Task-number: QTCREATORBUG-10454
Change-Id: I480d16423a976a025bb8c71046610a46f9d7b0fd
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
The following snippet demonstrates the problem:
--- snip ---
// comment \
#include <something.h>
...
class Foo
{
...
};
--- snap ---
If there are >=9 empty/preprocessor lines, the preprocessed source
becomes
// comment \
# 12 "file.cpp"
...
The lexer considers the line marker as a continued C++ comment, and
highlighting is broken
Change-Id: I30a2fc7d19b279316e9273697179c90d81099573
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
This takes too much memory. For qtcreator.pro the numbers are as
follows:
Patch applied: ~ 1600MB (RES)
Patch reverted: ~ 510MB (RES)
This reverts commit 4c2daa90ce.
Task-number: QTCREATORBUG-10973
Change-Id: I843bd7c1ea4a26a1ec55ddc14c2a34a98d040922
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Robert Loehning <robert.loehning@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
This adds definitions for the macros __FILE__, __LINE__, __DATE__ and
__TIME__ on demand.
As a side effect, this also introduces highlighting for the uses of
these macros.
Task-number: QTCREATORBUG-8036
Change-Id: Ib7546c7d45d2eecbc50c7883fc684e3497154405
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
Breaks highlighting for macros using the predefined macros.
This reverts commit 1d834c1126.
Change-Id: Ic13c407e293a806a63ff30153864530df6a32e47
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Preprocessor variables __LINE__,__FILE__,__TIME__,__DATE__ where destroying
the following systems when affected variables were standing within the
same line with those variables:
* highlighting
* refactoring
* local renaming
Task-number: QTCREATORBUG-8036
Change-Id: I1a4b919d15812872ca5a8e63b1031ec1ab144c22
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
