| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
It assumes LF line-endings
Change-Id: I7bfeb4b6d4db2fd6457030e2d21c240534de9cd2
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, always write into a unique temporary directory in
QDir::tempPath().
Where applicable, read the test source from files instead of first
writing the file.
Some clean ups in test_codegen*.
Change-Id: Id48dc50c6ca16252edfd9fc8a86ba0de9f9be486
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the actual include_next logic and thus completes
commit b934cc1
C++: pass #include_next down to CppPreprocessor::tryIncludeFile
commmit 140b502
C++: Highlight argument to gcc's #include_next extension
Based on https://gcc.gnu.org/onlinedocs/cpp/Wrapper-Headers.html
Task-number: QTCREATORBUG-10225
Change-Id: I7eef7f5ea64a114f6d092304d32b72c55c2ce134
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
|
| |
|
|
|
|
| |
Task-number: QTCREATORBUG-13422
Change-Id: I3648bf44760fdac4e8e1e79652519136af6032c8
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
| |
...in CPlusPlus::Document due to cyclic includes.
Task-number: QTCREATORBUG-11457
Change-Id: I1ca19c901c26d9984d795a61879dd6b41c57096c
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
For the quick fix AddIncludeForUndefinedIdentifier, if no class is found
via the locator, check the "Qt include paths" for a header file with the
same name as the class name.
Task-number: QTCREATORBUG-9538
Change-Id: I13c86844c2ff653fa479dc91eb109af2a6d76fae
Reviewed-by: Lorenz Haas <lykurg@gmail.com>
Reviewed-by: hjk <hjk121@nokiamail.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>
|
| |
|
|
|
|
|
|
|
| |
...by detecting include groups (separated by new lines, include types
and same dir prefix).
Task-number: QTCREATORBUG-9317
Change-Id: I73e80fdc715104901cb2d4f5b15b4cab5d04d305
Reviewed-by: Erik Verbruggen <erik.verbruggen@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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
Change-Id: I902ebd73e039b8c3f44eca456be87809d1e1d3a4
Reviewed-by: hjk <qthjk@ovi.com>
|
| |
|
|
|
| |
Change-Id: I9d51798cb4d95141d30b0609d03cd1d199088f0a
Reviewed-by: hjk <qthjk@ovi.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Generated tokens do not have a position in any source file, so not try
to indent them. Previously, the 'source' used was the scratch buffer,
which would not contain newlines, so the indent depth would be the
length of the scratch buffer at that point.
Task-number: QTCREATORBUG-7262
Change-Id: If94213d6dffd13dd2b47c7038ec2398ad925d904
Reviewed-by: Yuchen Deng <loaden@gmail.com>
Reviewed-by: Thomas Hartmann <Thomas.Hartmann@nokia.com>
|
| |
|
|
|
| |
Change-Id: I60d25109ae8fe3628b1899078a21010263787c33
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>
|
