We use a value of 200, which is also GCC's default.
Fixes: QTCREATORBUG-28770
Change-Id: Id02b324cd2ffa81a709441a5d93856bcd06501c3
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The starts with CppDocument::filePath(), plus a bit of the fallout
This is one patch of potentially many. It is hard to draw the
line where to stop this kind of chunk, this here converts a few
additional functions for which including it in the patch looked
like less churn than without.
Converting is mostly fromString/toString, with a few exceptions
for "already seem" like caches, that use cheaper "path()" to
avoid likely performance regressions (on Windows FilePath
comparison is currently case-insenstive, and more expensive).
There should be no difference for local operation with this patch.
Change-Id: I7b35f98a0a6f0bfed4ea0f8f987faf586f7a8f2b
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>
The preprocessor operates on QByteArray, making it less
convenient to use strings helps preventing accidental
conversion roundtrips.
Change-Id: Ifb2068a8fed137c52b05f2979b99cbce3462151e
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@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>
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>
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>
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>
By lexing the first token after a macro call (meaning: the token after
the closing parenthesis (which was passed to handleFunctionLikeMacro
which in turn pushed it back into the token buffer)), a token buffer
might be popped, which unblocks the macro that generated the actual
param pack. The effect was that if this happens in the expansion of a
recursive macro (with parameters!), the preprocessor ended up in an
infinite loop.
Task-number: QTCREATORBUG-9015
Task-number: QTCREATORBUG-9447
Change-Id: I0d83c59188ec15c4a948970e9fa944a17d765475
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
Doing so resulted in an incorrect position for the EOF token when the
preprocessed output would be parsed. That in turn leads to incorrect
insertion positions for refactoring actions.
This is especially true when a file contains only preprocessor
directives: the EOF token would point to line 1 column 1, which is
usually not the place where code should be inserted.
Change-Id: I7d359aa7a6c04bc52c8b873fd49ad6afc3a77319
Reviewed-by: hjk <hjk121@nokiamail.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>
Reduce the padding in some often-used structs for 64bit machines.
32bit machines should also profit from most changes, but to a
lesser degree.
Change-Id: Ic4c67b94e962731de4f31164c52a372d78944ccc
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Track the typical #ifndef/#define/#endif usage in header files to see if
the macro is an include guard. If so, store it in the Document. No
behavioural change, just recording the name.
This can be used in the future to track if a file needs to be re-parsed
when a macro changes: if it was used in the file, and not defined in it
nor being the include-guard, a file should be re-preprocessed and
re-parsed.
It can also be used to check if two files have the same include guard.
Change-Id: I2715f529997a7b24a11bdbc6150652e2669f1a46
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
This does not yet resolve the file using the proper mechanism.
Change-Id: I04913e8b01ae0c3411961f0c1cffe07202f06a0a
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Summary of most relevant items:
- Preprocessor output format change. No more gen true/false. Instead
a more intuitive and natural expansion (like from a real compiler) is
performed directly corresponding to the macro invocation. Notice that
information about the generated tokens is not lost, because it's now
embedded in the expansion section header (in terms of lines and columns
as explained in the code). In addition the location on where the macro
expansion happens is also documented for future use.
- Fix line control directives and associated token line numbers.
This was not detected in tests cases because some of them were
actually wrong: Within expansions the line information was being
considered as originally computed in the macro definition, while
the desired and expected for Creator's reporting mechanism (just
like regular compilers) is the line from the expanded version
of the tokens.
- Do not allow for eager expansion. This was previously being done
inside define directives. However, it's not allowed and might
lead to incorrect results, since the argument substitution should
only happen upon the macro invocation (and following nested ones).
At least GCC and clang are consistent with that. See test case
tst_Preprocessor:dont_eagerly_expand for a detailed explanation.
- Revive the 'expanded' token flag. This is used to mark every token
that originates from a macro expansion. Notice, however, that
expanded tokens are not necessarily generated tokens (although
every generated token is a expanded token). Expanded tokens that
are not generated are those which are still considered by our
code model features, since they are visible on the editor. The
translation unit is smart enough to calculate line/column position
for such tokens based on the information from the expansion section
header.
- How expansions are tracked has also changed. Now, we simply add
two surrounding marker tokens to each "top-level" expansion
sequence. There is an enumeration that control expansion states.
Also, no "previous" token is kept around.
- Preprocessor client methods suffered a change in signature so
they now receive the line number of the action in question as
a paramater. Previously such line could be retrieved by the client
implementation by accessing the environment line. However, this
is not reliable because we try to avoid synchronization of the
output/environment lines in order to avoid unnecessary output,
while expanding macros or handling preprocessor directives.
- Although macros are not expanded during define directives (as
mentioned above) the preprocessor client is now "notified"
when it sees a macro. This is to allow usage tracking.
- Other small stuff.
This is all in one patch because the fixes are a consequence
of the change in preprocessing control.
Change-Id: I8f4c6e6366f37756ec65d0a93b79f72a3ac4ed50
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
Make sure the environment line is consistent during preprocessor
directives and identifier handling so clients can rely on consistent
information. Particularly important for macro usages.
New tests also added.
Change-Id: I962a39a86cd17b8d945d2959c2c95e2d258ea3e6
Reviewed-by: hjk <qthjk@ovi.com>
Due to latest changes the macro arguments were no longer being tracked.
Then they were no available in the document's macro uses. The patch also
makes sure that the preprocessor condition to be expanded is spelled
exactly as in the source code (this guarantees that offsets will be
properly calculated).
Change-Id: I8aff0c3aca0c528ef2c4bcfa56ff1c3da2961060
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
This rewrite fixes a couple of issues with the pre-processor. It now
supports:
- macros in macro bodies
- stringification of parameters [cpp.stringize]
- the concatenation operator [cpp.concat]
- #include MACRO_HERE
- defined() inside macro bodies used in pp-conditions.
Change-Id: Ifdb78041fb6afadf44f939a4bd66ce2832b8601f
Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
The macro used to be at the same line as the first token after the
closing parenthesis.
Change-Id: I4c2d7317632baf612900e84572017aeb247d0585
Reviewed-by: Erik Verbruggen <erik.verbruggen@nokia.com>
