[Qt-creator] Need help understanding some qt-creator source

[Typz]

It seems to work correctly with the attached patch, which tries to go
through the "regular" code for these special compiler macros. The patch is
definitely not clean yet, though.

It may actually be better to automatically register Macro objects for
these, so the macros can be resolved normally (and highlighted, and usage
tracked like any regular macro), and simply replace the "definitionTokens"
by the appropriate value.

Unfortunately, i'm not sure i can provide a proper patch soon.

-- 
Francois


On Tue, Sep 10, 2013 at 6:48 PM, Typz <thetypz at gmail.com> wrote:

> It does not help the semantic analyzer in your case, but would help if
> used to make some function names unique for example.
>
> Generally, this is really just the "normal" preprocessor behavior, which
> is required in any case.
>
> The problem is not that the token is being replaced, but instead that the
> replacement itself is not properly handled: for regular macros, it works
> just fine.
>
> Btw, it can be noted that these special macros are also not highlighted.
>
> --
> Francois
>
> On 10 sept. 2013, at 18:31, Simon Schäfer <simonschaefer at posteo.de> wrote:
>
> > Am 10.09.13 16:28, schrieb Erik Verbruggen:
> >> On Sep 10, 2013, at 14:57, Simon Schäfer <simonschaefer at posteo.de>
> wrote:
> >>
> >>> Hello
> >>>
> >>> I try to understand some of the code of the creator, because I would
> >>> like to remove it, it is the reason of a bug (QTCREATORBUG-8036, it
> >>> still effects master) that annoys me. I can't figure out what it is
> used
> >>> for. The code I am talking about is in pp-engine.cpp:
> >>>
> >>> bool Preprocessor::handleIdentifier(PPToken *tk)
> >>>
> >>> There the representations of some preprocessor macros are internally
> >>> replaced by their meanings. For Example __LINE__ is replaced by the
> text
> >>> "9". This leads to strange behaviour for highlighting and even
> >>> re-factoring, because the editor determines the length of a token not
> by
> >>> the space it uses in the view but by the length of its text. So for the
> >>> above example the length is 1 instead of 8.
> >>>
> >>> The following example code can help you understand the Problem:
> >>>
> >>> <snip>
> >>> #include <QCoreApplication> // line 1
> >>>
> >>> #include <QDebug>
> >>>
> >>> int main(int argc, char *argv[])
> >>> {
> >>>    int abcd = 0;
> >>>
> >>>    qDebug () << __LINE__ << abcd; // line 9
> >>>    qDebug () << __LINE__ << abcd; // line 10
> >>>    return 0;
> >>> }
> >>> <snap>
> >>>
> >>> If you click on abcd it will highlight a block of 4 chars within the
> >>> first __LINE__ and another block of 4 in the second __LINE__ (moved one
> >>> to the right). If you now use "Rename Symbol under cursor" and type
> >>> abcde strange stuff happens.
> >>>
> >>> My basic question is why are those Preprocessor texts used instead of
> >>> the displayed texts?
> >> Um, because semantic highlighting uses information from the parser to
> find out that a piece of text is an identifier, and actually the identifier
> it needs to highlight? Or did I misunderstand the question?
> > How does it help the semantic highlighter that __LINE__ is replaced by a
> > string representation of the current line number or __FILE__ is for
> > example: "helloworld.cpp"?
> > What I would like to commit is the following:
> http://pastebin.com/3AZvPj2e
> > What keeps me holding it back is that the txt's where there for a reason
> > in the first place, but I can't figure out what they are for.
> >
> > Cheers
> > Simon
> > _______________________________________________
> > Qt-creator mailing list
> > Qt-creator at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/qt-creator
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20130910/7d99d4b2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pp-engine.diff
Type: application/octet-stream
Size: 4278 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20130910/7d99d4b2/attachment.obj>