User forums > Nightly builds

The 08 February 2014 build (9639) is out.

<< < (6/8) > >>

MortenMacFly:

--- Quote from: ollydbg on February 12, 2014, 03:51:52 am ---m_TokenIndex is always remain/reset to the same value, so Tokenizer won't go forward any more.

--- End quote ---
That's too bad. Can you fix it? Otherwise I would strongly recommend to revert this change completely - it makes C::B unusable with wx30.

Edit: What SVN revision this belongs to, btw?! ???

ollydbg:

--- Quote from: MortenMacFly on February 12, 2014, 08:16:13 am ---
--- Quote from: ollydbg on February 12, 2014, 03:51:52 am ---m_TokenIndex is always remain/reset to the same value, so Tokenizer won't go forward any more.

--- End quote ---
That's too bad. Can you fix it? Otherwise I would strongly recommend to revert this change completely - it makes C::B unusable with wx30.

Edit: What SVN revision this belongs to, btw?! ???

--- End quote ---

Follow this post:
Re: Several improvements to Code Completion plugin
and
Re: Several improvements to Code Completion plugin

The change is rev 9369, you can see it from the git log message in my previous posts.

--- Quote ---Revision: f7cb07c8dcf613f6786eaf0ee34e908ec218d2c8
Author: ollydbg <ollydbg@2a5c6006-c6dd-42ca-98ab-0921f2732cef>
Date: 2013-9-29 16:25:10
Message:
* CC: reliable working of UngetToken() when macro expansion is involved, it set the undo index value correctly(thanks Huki)

* CC: avoid take backward step (UngetToken) twice in the Tokenizer class
- CC: comments added for Tokenizer class

git-svn-id: https://svn.code.sf.net/p/codeblocks/code/trunk@9369 2a5c6006-c6dd-42ca-98ab-0921f2732cef

--- End quote ---

Currently I can't fix it, but I'm debugging now for hours......

ollydbg:
The code do the macro replacement is a mass, the big error looks like it is not the way a C Processor do the replacement.

For example, if we have such code


--- Code: ---/****************************************/

#define A(x,y)  (x+y)
#define B 1
#define C 2


#if A(B,C)

void f1234();

#endif

void f2345();


// f123      //f1234
// f234      //f2345

--- End code ---
To expand the A(B,C), we should first apply the macro definition 1, so it becomes (B+C), then we should "rescan" the result token list, and finally get the (2+1), so the final result is 3.

But from my point of view, our Tokenizer don't have a "rescan" stage, the trick thing is that it did some text substitute on formal parameter to actual parameter translation, some kind of recursive call.

Note, with the latest cc-test frame, I get such result

--- Code: ----PASS:  f234  f2345
*FAIL:  f123  f1234
--------------------------------------------------------
Total 2 tests, 1 PASS, 1 FAIL
--------------------------------------------------------

--- End code ---
So, the #if branch is abandoned.

EDIT:
If I change the #if line to "#if A(2,3)", then I get two PASSes.

--- Code: ----PASS:  f234  f2345
-PASS:  f123  f1234
--------------------------------------------------------
Total 2 tests, 2 PASS, 0 FAIL
--------------------------------------------------------

--- End code ---

ollydbg:
@morten, revert rev9369 can avoid the hang issue, so I'm going to commit the change now. (This is a workaround, not a true fix).

osdt:

--- Quote from: ollydbg on February 12, 2014, 02:48:24 pm ---@morten, revert rev9369 can avoid the hang issue, so I'm going to commit the change now. (This is a workaround, not a true fix).

--- End quote ---

@ollydbg: reverting r9638 fixes this issue too!

I can confirm that r9639 has this issue while r9619 works flawlessly. Between this revisions, CC-related changes are r9636, r9638 and r9639.

- osdt

Navigation

[0] Message Index

[#] Next page

[*] Previous page