Hello, everyone! I compiled SVN6056 version, and do not use already existing default.conf, but by the CB to generate a new configuration file.
After I found: vector <int> can already be a normal CB resolved, but the string and wstring not be resolved CB. As shown in the following code: there is no intelligence tips.
#include <iostream>
#include <string>
int main()
{
std::string s;
s.
return 0;
}
#include <iostream>
#include <string>
using namespace std;
int main()
{
string s;
s.
return 0;
}
[attachment deleted by admin]
but if i use this code, it's work!
#include <iostream>
#include <string>
using namespace std;
int main()
{
basic_string<char> s;
s.
return 0;
}
but if use wchar_t, it's no-work too.
#include <iostream>
#include <string>
using namespace std;
int main()
{
basic_string<wchar_t> ws;
ws.
return 0;
}
[attachment deleted by admin]
but this code is work fine.
#include <iostream>
#include <string>
int main()
{
std::basic_string<char> s;
s.
return 0;
}
[attachment deleted by admin]
the string's ancestor is lost.that is why it can not work.
Note:it work in svn 5986.
Quote from: blueshake on January 06, 2010, 06:03:44 AM
the string's ancestor is lost.that is why it can not work.
I don't thinks that's the reason. In fact I think I found it.
I've submitted some minor enhancements to debug SmartSense.
If you do exactly the following (with this code base):
0.) Open C::B with debug log enabled
1.) Open the CC testing project
2.) Activate the STL project
3.) Open the stl.cpp file
4.) Uncomment the "s." line (do
not save!)
5.) Go to the symbols browser, enable SmartSense
6.) Clear the Debug log
7.) After the "
s." try CTRL+SPACE (CC kicks in)
8.) Notice this output in the debug log:
FindCurrentFunctionStart() Looking for tokens in 'C:\Devel\CodeBlocks\src\plugins\codecompletion\testing\stl.cpp'
FindCurrentFunctionStart() Found 1 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main(void)', tF='C:\Devel\CodeBlocks\src\plugins\codecompletion\testing\duplicate_header.cpp', tStart=52, tEnd=117
FindCurrentFunctionStart() Function out of bounds: tN='int main(void)', tF='C:\Devel\CodeBlocks\src\plugins\codecompletion\testing\duplicate_header.cpp', tStart=52, tEnd=117, line=9 (size_t)line=9
FindCurrentFunctionStart() Can't determine current function...
You will realise that the token returned does
not match in the file name even though
FindTokensInFile was given the right file name. The result: The function bounds check will fail and thus CC cannot code complete (no matter if it's string or vector or alike).
blueshake: I believe this is related to the "real time parse" where probably some false file information is passed... Could that be? Can you please try SVN trunk?
Quoteblueshake: I believe this is related to the "real time parse" where probably some false file information is passed... Could that be? Can you please try SVN trunk?
ok,i will try it.but I just pass the filename .nothing more.
and see the string information in svn 5986 and svn 6056.see the screen shot.
[attachment deleted by admin]
um,it seems something relatived to the files.
in svn 6056(which not work),the debug log output:
only 141 files are parsed.QuoteParsing stage done (141 total parsed files, 28885 tokens in 0 minute(s), 1.781 seconds).
in svn 5986(
which work,I have apply the real-time parser in my local copy with this svn version),the debug log output:
164 files are parsed.QuoteParsing stage done (164 total parsed files, 30028 tokens in 0 minute(s), 1.985 seconds).
Quote from: blueshake on January 06, 2010, 12:06:23 PM
and see the string information in svn 5986 and svn 6056.see the screen shot.
Hmmm... weird. So it could also e related to OllyDbg's modifications for the
typedef handling. Because it's in fact a
typedef.
mention to typedef ,but these codes work fine.
#include <iostream>
using namespace std;
class qq
{
int x;
int y;
};
typedef qq pp;
typedef pp tt;
int main()
{
cout << "Hello world!" << endl;
return 0;
}
see the attachmet.
[attachment deleted by admin]
Quote from: blueshake on January 06, 2010, 12:23:31 PM
QuoteParsing stage done (141 total parsed files, 28885 tokens in 0 minute(s), 1.781 seconds).
QuoteParsing stage done (164 total parsed files, 30028 tokens in 0 minute(s), 1.985 seconds).
Hmmm... could you do me a favour and try r6044 versus r6045? r6044 should still work. The modifications between r5986 and r6044 should not matter.
Quote from: MortenMacFly on January 06, 2010, 01:01:49 PM
Quote from: blueshake on January 06, 2010, 12:23:31 PM
QuoteParsing stage done (141 total parsed files, 28885 tokens in 0 minute(s), 1.781 seconds).
QuoteParsing stage done (164 total parsed files, 30028 tokens in 0 minute(s), 1.985 seconds).
Hmmm... could you do me a favour and try r6044 versus r6045? r6044 should still work. The modifications between r5986 and r6044 should not matter.
It is a shame to say that I don't know how to do it.
and I turn the real-time parse off in latest svn with nothing changed.
the issue still exist.so I think there is something wrong with parserthread.
I found a big problem.
try these codes.
#include <iostream>
using namespace std;
class qq
{
int x;
int y;
};
typedef qq pp;
typedef pp tt;
tt cc;//
int main()
{
cout << "Hello world!" << endl;
return 0;
}follow the steps below:
-save the codes in cb
-close the cb application.
-restart the cb ----------------at this point .the parser work fine.
-add any codes below tt cc;//-----------------then the variable can not be parsed correctly.there is no any variable in the symboltree.
Quote from: blueshake on January 06, 2010, 01:19:01 PM
the issue still exist.so I think there is something wrong with parserthread.
OK - after some tests it's definitely related to:
http://forums.next.codeblocks.org/index.php/topic,11754.msg79756.html#msg79756
Stage management is not working as before. OllyDbg?!
Quote from: MortenMacFly on January 06, 2010, 02:27:20 PM
Quote from: blueshake on January 06, 2010, 01:19:01 PM
the issue still exist.so I think there is something wrong with parserthread.
OK - after some tests it's definitely related to:
http://forums.next.codeblocks.org/index.php/topic,11754.msg79756.html#msg79756
I will check this bug. It seems the preprocessor of "include" statement is not correct.
QuoteStage management is not working as before. OllyDbg?!
what does "stage management" means???
Quote from: ollydbg on January 06, 2010, 02:34:09 PM
QuoteStage management is not working as before. OllyDbg?!
what does "stage management" means???
It meant the modifications you did with
Tokenizer state (introducing the
enum TokenizerState).
For example (
void ParserThread::DoParse()):
Before:
else if (token==ParserConsts::kw_operator)
{
bool oldState = m_Tokenizer.IsSkippingUnwantedTokens();
m_Tokenizer.SetSkipUnwantedTokens(false);
m_Tokenizer.SetOperatorState(true);
After:
TokenizerState oldState = m_Tokenizer.GetState();
m_Tokenizer.SetState(tsSkipNone);
...or (
void ParserThread::HandleClass(EClassType ct, const wxString& templateArgs)):
Before:
// don't forget to reset that if you add any early exit condition!
bool oldState = m_Tokenizer.IsSkippingUnwantedTokens();
m_Tokenizer.SetSkipUnwantedTokens(false);
After:
// don't forget to reset that if you add any early exit condition!
TokenizerState oldState = m_Tokenizer.GetState();
m_Tokenizer.SetState(tsSkipUnWanted);
This might be a mistake...?!
Ok, let's explain some thing about introduce a "state" variable in the Tokenizer.
There are several reasons:
1, Before that, Tokenizer use a bool variable SkipUnWanted to determine where the Tokenizer need to skip some statement like assignment "=" or array subscirpt "[]".
2, Angle Brace is a single token return from the Tokenizer::GetToken or Tokenizer::PeekToken.
But when we want to read the template argument. like the code below:
template < XXXX >
class AAA{
...
}
I would perfer the Tokenizer return the whole string < XXXX >
3,When we are entering some context, we should save the context state.
Before:
bool oldState = m_Tokenizer.IsSkippingUnwantedTokens();
m_Tokenizer.SetSkipUnwantedTokens(false);
m_Tokenizer.SetOperatorState(true);
Do some parsing..
m_Tokenizer.SetSkipUnwantedTokens(oldState);
But I think a bool variable is not enough to describe all the context, so ,I use a more flexiable enum variable.
The benifit is that Currently, CC is only a partily parser, which means some statements are skiped( currently, the member function body is skiped, the statement in the right side of an assignment is skiped too). But for the long run, I think add a state is convient :D
Quote from: ollydbg on January 06, 2010, 03:06:06 PM
But for the long run, I think add a state is convient :D
I know, that's why I applied the patch. ;-) However, there seems to be something wrong with the new implementation where you surely can help... :P
I'm confused about your discussion. Does this bug comes from the "real-time CC" or the patch of my modification of Tokenizer??? :?
Quote from: ollydbg on January 07, 2010, 01:13:12 PM
Does this bug comes from the "real-time CC" or the patch of my modification of Tokenizer??? :?
From the new
Tokenizer states. Have another look at my previous post. The two examples in the code do obviously the opposite of what was done previously. Is this intended behaviour of yours?
Meaning, shouldn't we apply this patch:
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 6058)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -403,7 +403,7 @@
// need to reset tokenizer's behavior
// don't forget to reset that if you add any early exit condition!
TokenizerState oldState = m_Tokenizer.GetState();
- m_Tokenizer.SetState(tsSkipUnWanted);
+ m_Tokenizer.SetState(tsSkipNone);
m_Str.Clear();
m_LastToken.Clear();
@@ -1385,7 +1385,7 @@
wxString next = m_Tokenizer.PeekToken(); // named namespace
if (next==ParserConsts::opbrace)
{
- m_Tokenizer.SetState(tsSkipNone);
+ m_Tokenizer.SetState(tsSkipUnWanted);
// use the existing copy (if any)
Token* newToken = TokenExists(ns, m_pLastParent, tkNamespace);
However, you changes quite a lot related to skipping so I might be wrong...
No, the first place when entering the DoParse function. we should set the state to "
// need to reset tokenizer's behavior
// don't forget to reset that if you add any early exit condition!
TokenizerState oldState = m_Tokenizer.GetState();
m_Tokenizer.SetState(tsSkipUnWanted);
m_Str.Clear();
....
This is the default setting.
Quote from: ollydbg on January 07, 2010, 02:08:26 PM
No, the first place when entering the DoParse function. we should set the state to "
Could you explain '' a little more? Set to what exactly? And what's with the second one?
Quote from: MortenMacFly on January 07, 2010, 02:35:01 PM
Quote from: ollydbg on January 07, 2010, 02:08:26 PM
No, the first place when entering the DoParse function. we should set the state to "
Could you explain '' a little more? Set to what exactly? And what's with the second one?
OK, let me explain the old way( before the patch of Tokenizer state related code).
There is a variable named: m_SkipUnwantedTokens(true), you can see this from the constructor of Tokenizer, so, by default, this means in normal situation, we should let the Tokenizer skip some words. In very merely case, this variable would set to "true" to let the Tokenizer never skip anything.
So, the new way ( after applying my patch), I would set the state to "skipUnWanted", so this is the same behavour like the old one.
For the second place:
I'm sorry, that's my mistake, you are right!
Quote from: ollydbg on January 07, 2010, 02:55:58 PM
OK, let me explain the old way( before the patch of Tokenizer state related code). [...]
Thanks, that made things clear to me.
So finally, what happened to:
m_Tokenizer.SetOperatorState(true);This is not applied anymore if I got the new implementation right. Look again:
Quote from: MortenMacFly on January 06, 2010, 02:47:09 PM
For example (void ParserThread::DoParse()):
Before:
else if (token==ParserConsts::kw_operator)
{
bool oldState = m_Tokenizer.IsSkippingUnwantedTokens();
m_Tokenizer.SetSkipUnwantedTokens(false);
m_Tokenizer.SetOperatorState(true);
After:
TokenizerState oldState = m_Tokenizer.GetState();
m_Tokenizer.SetState(tsSkipNone);
Any comments on that...?!
Quote from: MortenMacFly on January 07, 2010, 03:05:07 PM
So finally, what happened to:
m_Tokenizer.SetOperatorState(true);
This is not applied anymore if I got the new implementation right. Look again:
Quote from: MortenMacFly on January 06, 2010, 02:47:09 PM
For example (void ParserThread::DoParse()):
Before:
else if (token==ParserConsts::kw_operator)
{
bool oldState = m_Tokenizer.IsSkippingUnwantedTokens();
m_Tokenizer.SetSkipUnwantedTokens(false);
m_Tokenizer.SetOperatorState(true);
After:
TokenizerState oldState = m_Tokenizer.GetState();
m_Tokenizer.SetState(tsSkipNone);
Any comments on that...?!
I personally don't think we need another variable to specify we are after the operator statement.
for example:
void AAA::operator + (XXXX)
or
void AAA::operator = (XXXX)
In such situations, the word after "operator" should return from GetToken() function. ( They won't be skipped ). So, I think once we meet a "operator" word, we need to set the TokenizerState to "tsSkipNone".
Is that OK? :D
Test report:
rev 6067 trunk windows.
CodeCompletion testing workspace:
function_args.cpp can't full pass.
// i_integer = from.i_;
// f_float = from.f_;
stl.cpp can't fully pass
std::string ss;
ss.
stl_namespace.cpp can't fully pass.
string s;
s.
structs_typedefs.cpp can't fully pass.
std::string ss;
my_string ms;
ss.
I'm try to find the bug, but these days I'm a little busy :?
Ok, have a further test, I'm fully agree with blueshake's No ancestor's in the current string Token (http://forums.next.codeblocks.org/index.php/topic,11800.msg80086.html#msg80086), so, the "string" have no ancestors, that's the reason why we don't have string members list auto completion.
Quote from: ollydbg on January 11, 2010, 08:41:02 AM
Ok, have a further test, [...]
Just for the record: I've implemented some more debugging facilities with the last commit of mine. You can now save the tokens tree to an ASCii file from the CC debug window.
Quote from: MortenMacFly on January 11, 2010, 08:49:24 AM
Quote from: ollydbg on January 11, 2010, 08:41:02 AM
Ok, have a further test, [...]
Just for the record: I've implemented some more debugging facilities with the last commit of mine. You can now save the tokens tree to an ASCii file from the CC debug window.
Yes, I have noticed that, it is a great improvement!
Quote from: ollydbg on January 11, 2010, 08:41:02 AM
Ok, have a further test, I'm fully agree with blueshake's No ancestor's in the current string Token (http://forums.next.codeblocks.org/index.php/topic,11800.msg80086.html#msg80086), so, the "string" have no ancestors, that's the reason why we don't have string members list auto completion.
I wonder if the modification you did in
void ParserThread::ReadClsNames(wxString& ancestor) are 100% correct. NOtice this code snippet:
Before:
else if ( wxIsalpha(current.GetChar(0))
&& ( (m_Tokenizer.PeekToken() == ParserConsts::semicolon)
|| (m_Tokenizer.PeekToken() == ParserConsts::comma)) )
{
TRACE(_T("ReadClsNames() : Adding variable '%s' as '%s' to '%s'"),
current.wx_str(),
m_Str.wx_str(),
(m_pLastParent ? m_pLastParent->m_Name.wx_str():_T("<no-parent>")));
Token* newToken = DoAddToken(tkTypedef, current, m_Tokenizer.GetLineNumber());
if (!newToken)
break;
else
{
wxString tempAncestor = ancestor;
newToken->m_AncestorsString = tempAncestor;
newToken->m_ActualType = tempAncestor;
newToken->m_Type = tempAncestor;
}
}
After:
else if ( wxIsalpha(current.GetChar(0))
&& ( (m_Tokenizer.PeekToken() == ParserConsts::semicolon)
|| (m_Tokenizer.PeekToken() == ParserConsts::comma)) )
{
TRACE(_T("ReadClsNames() : Adding variable '%s' as '%s' to '%s'"),
current.wx_str(),
m_Str.wx_str(),
(m_pLastParent ? m_pLastParent->m_Name.wx_str():_T("<no-parent>")));
m_Str.clear();
wxString tempAncestor = ancestor;
m_Str = tempAncestor;
Token* newToken = DoAddToken(tkTypedef, current, m_Tokenizer.GetLineNumber());
if (!newToken)
break;
else
{
newToken->m_AncestorsString = tempAncestor;
//newToken->m_ActualType = tempAncestor;
//if (m_IsPointer)
//{
// newToken->m_Type = tempAncestor + _T("*");
//}
//else
//newToken->m_Type = tempAncestor;
}
}
You are not setting the
m_Type etc. This is commented out. Is this intended (and if so: Why)?
I just do a test, that, I create a simple cpp file from basci_string.
It seems the parserThread failed in parsing these statement:
template<typename _CharT, typename _Traits, typename _Alloc>
inline basic_string<_CharT, _Traits, _Alloc>::
basic_string()
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
: _M_dataplus(_S_empty_rep()._M_refdata(), _Alloc()) { }
#else
: _M_dataplus(_S_construct(size_type(), _CharT(), _Alloc()), _Alloc()) { }
#endif
// operator+
/**
* @brief Concatenate two strings.
* @param lhs First string.
* @param rhs Last string.
* @return New string with value of @a lhs followed by @a rhs.
*/
template<typename _CharT, typename _Traits, typename _Alloc>
basic_string<_CharT, _Traits, _Alloc>
operator+(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
const basic_string<_CharT, _Traits, _Alloc>& __rhs)
{
basic_string<_CharT, _Traits, _Alloc> __str(__lhs);
__str.append(__rhs);
return __str;
}
because when I read the TRACE Debug output, these code were failed.
You can just copy the testString.txt(see the attachment of this post)'s content to a empty project, and set the
#define PARSERTHREAD_DEBUG_OUTPUT 1
Then view the debug log output.
Note: the testString.txt is just a modified source from STL header file of basic_string.
You can see the last sentence of the debug log.
DoAddToken() : Found token (parent).
DoAddToken() : Created token='compare', file_idx=1, line=2016
GetActualTokenType() : Searching within m_Str='int'
GetActualTokenType() : Compensated m_Str='int'
GetActualTokenType() : Found 'int'
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'compare' (172), type 'int', actual 'int'. Parent is basic_string (1)
DoParse() : Loop:m_Str='', token=';'
DoParse() : Loop:m_Str='', token='int'
DoParse() : Loop:m_Str='int ', token='compare'
HandleFunction() : Adding function 'compare': m_Str='int '
HandleFunction() : name='compare', args='(size_type __pos, size_type __n1, const _CharT* __s, size_type __n2)', peek='const'
HandleFunction() : !(Ctor/Dtor) 'compare', m_Str='int ', localParent='<none>'
HandleFunction() : Adding function 'compare', ': m_Str='int ', enc_ns='nil'.
HandleFunction() : Add token name='compare', args='(size_type __pos, size_type __n1, const _CharT* __s, size_type __n2)', return type='int '
GetStrippedArgs() : args='(size_type __pos, size_type __n1, const _CharT* __s, size_type __n2)'.
GetStrippedArgs() : stripped_args='(size_type,size_type,const _CharT*,size_type)'.
DoAddToken() : Found token (parent).
DoAddToken() : Created token='compare', file_idx=1, line=2042
GetActualTokenType() : Searching within m_Str='int'
GetActualTokenType() : Compensated m_Str='int'
GetActualTokenType() : Found 'int'
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'compare' (173), type 'int', actual 'int'. Parent is basic_string (1)
DoParse() : Loop:m_Str='', token=';'
DoParse() : Loop:m_Str='', token='}'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='inline'
DoParse() : Loop:m_Str='', token='#'
HandlePreprocessorBlocks() : Saving nesting level: 1
HandlePreprocessorBlocks() : Restoring nesting level: 1 (was 1)
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='basic_string'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='basic_string'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='basic_string'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='inline'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='inline'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='inline'
DoParse() : Loop:m_Str='', token='}'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='inline'
Parsing stage done (1 total parsed files, 174 tokens in 0 minute(s), 8.377 seconds).
Updating class browser...
Class browser updated.
if (token == ParserConsts::kw_template)
{
// There are some template defintions that are not working like
// within gcc headers (NB: This syntax is a GNU extension):
// extern template
// const codecvt<char, char, mbstate_t>&
// use_facet<codecvt<char, char, mbstate_t> >(const locale&);
m_Tokenizer.SetState(tsTemplateArgument);
wxString args = m_Tokenizer.GetToken();
token = m_Tokenizer.GetToken();
TRACE(_T("DoParse() : Template argument='%s', token ='%s'"), args.wx_str(), token.wx_str());
if (token==ParserConsts::kw_class)
{
m_Str.Clear();
if (m_Options.handleClasses)
HandleClass(ctClass, args);
else
SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
}
else if (token==ParserConsts::kw_struct)
{
m_Str.Clear();
if (m_Options.handleClasses)
HandleClass(ctStructure, args);
else
SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
}
else
{
SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
}
}
We should rethink the code above, for example, there are some template declaration like below:
template<typename _CharT, typename _Traits, typename _Alloc>
inline bool
operator<=(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
const basic_string<_CharT, _Traits, _Alloc>& __rhs)
{ return __lhs.compare(__rhs) <= 0; }
at this time, the "token string" behind the template argument is not "class" nor "struct", but a general function declaration. So, I think we should use a variable like "template argument" to specify the current context".
For example:
When the parser eat these strings "template<typename _CharT, typename _Traits, typename _Alloc>", we can set the variable "template argument", then we continue our DoParse Loop. next we add a Token, we should attach this "template argument" context to the Token. So, This variable is just like other variables like: m_Str( store the type information) or m_EncounteredTypeNamespaces (store the namespace in data types).
Any way, checking the next token after the template argument is not a correct way.
Quote from: ollydbg on January 11, 2010, 04:17:58 PM
Any way, checking the next token after the template argument is not a correct way.
True, but I still wonder why it works with vector and alike and why with any revision before applying your and blueshake's patch it used to work. There must be another error.
Will it be to replace the rules of the problem? This is CodeLite replacement rules:
EXPORT
WXDLLIMPEXP_CORE
WXDLLIMPEXP_BASE
WXDLLIMPEXP_XML
WXDLLIMPEXP_XRC
WXDLLIMPEXP_ADV
WXDLLIMPEXP_AUI
WXDLLIMPEXP_CL
WXDLLIMPEXP_LE_SDK
WXDLLIMPEXP_SQLITE3
WXMAKINGDLL
WXUSINGDLL
_CRTIMP
__CRT_INLINE
__cdecl
__stdcall
WXDLLEXPORT
WXDLLIMPORT
wxT
wxTopLevelWindowNative=wxTopLevelWindowMSW
wxWindow=wxWindowMSW
wxStatusBar=wxStatusBarBase
WXUNUSED
wxDEPRECATED
_T
ATTRIBUTE_PRINTF_1
ATTRIBUTE_PRINTF_2
WXDLLIMPEXP_FWD_BASE
WXDLLIMPEXP_FWD_CORE
DLLIMPORT
DECLARE_INSTANCE_TYPE
emit
Q_OBJECT
Q_PACKED
Q_GADGET
QT_BEGIN_HEADER
QT_END_HEADER
Q_REQUIRED_RESULT
Q_INLINE_TEMPLATE
Q_OUTOFLINE_TEMPLATE
_GLIBCXX_BEGIN_NAMESPACE(std)=namespace std{
_GLIBCXX_END_NAMESPACE=}
_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD)=namespace std{
_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)=namespace std{
_GLIBCXX_END_NESTED_NAMESPACE=}
_GLIBCXX_STD=std
WXDLLIMPEXP_SCI
__const=const
__restrict
__THROW
__wur
_STD_BEGIN=namespace std{
_STD_END=}
__CLRCALL_OR_CDECL
_CRTIMP2_PURE
Among them, through the following replacement rules, can support VC9 header file parsing:
_STD_BEGIN=namespace std{
_STD_END=}
__CLRCALL_OR_CDECL
hi,guys:
see what the template handle do,
if (token == ParserConsts::kw_template)
{
m_Tokenizer.SetState(tsTemplateArgument);
wxString args = m_Tokenizer.GetToken();
token = m_Tokenizer.GetToken();
TRACE(_T("DoParse() : template argument='%s', token ='%s'"), args.wx_str(), token.wx_str());
if (token==ParserConsts::kw_class)
{
m_Str.Clear();
if (m_Options.handleClasses)
HandleClass(ctClass,args);
else
SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
}
else if (token==ParserConsts::kw_struct)
{
m_Str.Clear();
if (m_Options.handleClasses)
HandleClass(ctStructure,args);
else
SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
}
else
{
SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
}
}
just as ollydbg said,when the the next token is not class or struct,the parser will skip to }/;,I think it is wrong here.
@blueshake:
Yes, the code is added by me.
else
{
SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
}
I nearly forget what's in the visualfc's patch, he use a different logic. So, I will check it.
@macfly
I will exam it, it seems the code before is not correct either, but it do show some code completion list.
Here is improved testString.txt, I have test in an old rev 5988, it seems the last part of file was skipped.
Eg, You can't find the declaration of this function.
inline wstring
to_wstring(long long __val)
{ return __gnu_cxx::__to_xstring<wstring>(&std::vswprintf,
4 * sizeof(long long),
L"%lld", __val); }
You can enable PARSERTHREAD_DEBUG_OUTPUT 1 to see the log.
I'm planning adding a variable to store the Template argument in the ParserThread.cpp.
Some thing like below:
if (token == ParserConsts::kw_template)
{
m_Tokenizer.SetState(tsTemplateArgument);
m_TemplateArgument = m_Tokenizer.GetToken();
m_Str.Clear();
token = m_Tokenizer.GetToken();
TRACE(_T("DoParse() : Reading Template argument='%s'"), m_TemplateArgument.wx_str());
m_Tokenizer.SetState(tsSkipUnwanted);
}
So, when we are about to add some tokens like "class" or "function", we can check m_TemplateArgument. if it is an wxEmptyString, then the currently token is a "normal" token, if not, the current token is a template token.
Also, I suggest that in the Token.h.
we can add a member to the Token class. like:
class Token : public BlockAllocated<Token, 10000>{
...
wxString m_TemplateArgument;
}
Any comments?
If you do this, do not forget to change the codes about mouse hover tip too. :D
Quote from: ollydbg on January 12, 2010, 03:49:54 AM
I'm planning adding a variable to store the Template argument in the ParserThread.cpp.
[...]
Sounds good.
Quote from: ollydbg on January 12, 2010, 03:49:54 AM
Also, I suggest that in the Token.h.
we can add a member to the Token class. like:
[...]
For what purpose? Displaying the template arguments?
Quote
For what purpose? Displaying the template arguments?
Yes, also, if we need to do some template instantiation, we need to store the template argument.
Currently, Further more, if a "class template" Token, we can use the "argument" field to store the template argument. But if it is a "function template" Token, we need another field. :D
hi,ollydbg:
I get some codes from the string test file.It seems the typedef can not handle correctly.
class basic_string
{
};
_GLIBCXX_BEGIN_NAMESPACE(std)
template<typename _Alloc>
class allocator;
template<class _CharT>
struct char_traits;
template<typename _CharT, typename _Traits = char_traits<_CharT>,
typename _Alloc = allocator<_CharT> >
class basic_string;
template<> struct char_traits<char>;
typedef basic_string<char> string;
#ifdef _GLIBCXX_USE_WCHAR_T
template<> struct char_traits<wchar_t>;
typedef basic_string<wchar_t> wstring;
#endif
#if (defined(__GXX_EXPERIMENTAL_CXX0X__) \
&& defined(_GLIBCXX_USE_C99_STDINT_TR1))
template<> struct char_traits<char16_t>;
template<> struct char_traits<char32_t>;
typedef basic_string<char16_t> u16string;
typedef basic_string<char32_t> u32string;
#endif
_GLIBCXX_END_NAMESPACE
//string aaaa;
//aaaa.
you can find that the string loses its ancestor.It work before.
Quote from: blueshake on January 12, 2010, 09:46:26 AM
you can find that the string loses its ancestor.It work before.
Exactly. That's what I noticed, too. Still: I don't see why that is. But it's most likely related to Ollydbg's patch. So I was hoping he'd help us...
Quote from: MortenMacFly on January 12, 2010, 10:11:17 AM
Quote from: blueshake on January 12, 2010, 09:46:26 AM
you can find that the string loses its ancestor.It work before.
Exactly. That's what I noticed, too. Still: I don't see why that is. But it's most likely related to Ollydbg's patch. So I was hoping he'd help us...
Ok, I will try my best to find the bug :D
This is a patch for testing, I just add a member variable to ParserThread and Token. It seems the parser works better. :D.
Also, I refined my testString.txt.
Comments and suggestion are welcome. :D
[attachment deleted by admin]
I noticed that we have forgot one Macro replacement rule
_GLIBCXX_END_NAMESPACE to }
in default.conf file , change to this
<TOKEN_REPLACEMENTS>
<ssmap>
<_GLIBCXX_END_NAMESPACE>
<![CDATA[}]]>
</_GLIBCXX_END_NAMESPACE>
<_GLIBCXX_BEGIN_NAMESPACE>
<![CDATA[+namespace]]>
</_GLIBCXX_BEGIN_NAMESPACE>
<_GLIBCXX_BEGIN_NAMESPACE_TR1>
<![CDATA[-namespace tr1 {]]>
</_GLIBCXX_BEGIN_NAMESPACE_TR1>
<_GLIBCXX_BEGIN_NESTED_NAMESPACE>
<![CDATA[+namespace]]>
</_GLIBCXX_BEGIN_NESTED_NAMESPACE>
<_GLIBCXX_END_NAMESPACE_TR1>
<![CDATA[}]]>
</_GLIBCXX_END_NAMESPACE_TR1>
<_GLIBCXX_END_NESTED_NAMESPACE>
<![CDATA[}]]>
</_GLIBCXX_END_NESTED_NAMESPACE>
<_GLIBCXX_STD>
<![CDATA[std]]>
</_GLIBCXX_STD>
</ssmap>
</TOKEN_REPLACEMENTS>
Edit
Also, this rule should be added to this function body
Tokenizer::SetReplacementString(_T("_GLIBCXX_END_NAMESPACE"), _T("}"));
void CodeCompletion::LoadTokenReplacements()
{
ConfigManager* cfg = Manager::Get()->GetConfigManager(_T("code_completion"));
ConfigManagerContainer::StringToStringMap& repl = Tokenizer::GetTokenReplacementsMap();
repl.clear();
if (!cfg->Exists(_T("token_replacements")))
{
// first run; add default replacements string
Tokenizer::SetReplacementString(_T("_GLIBCXX_STD"), _T("std"));
Tokenizer::SetReplacementString(_T("_GLIBCXX_BEGIN_NESTED_NAMESPACE"), _T("+namespace"));
Tokenizer::SetReplacementString(_T("_GLIBCXX_END_NESTED_NAMESPACE"), _T("}"));
Tokenizer::SetReplacementString(_T("_GLIBCXX_BEGIN_NAMESPACE"), _T("+namespace"));
Tokenizer::SetReplacementString(_T("_GLIBCXX_END_NAMESPACE_TR1"), _T("}"));
Tokenizer::SetReplacementString(_T("_GLIBCXX_BEGIN_NAMESPACE_TR1"), _T("-namespace tr1 {"));
}
else
cfg->Read(_T("token_replacements"), &repl);
}
By the way, I found it's hard to enter in the CC's configure dialog.
After that, CC works now !!!!
SVN 6077, this code work now.
#include <iostream>
#include <string>
using namespace std;
int main()
{
basic_string<char> bs;
bs.append("work fine!");
basic_string<wchar_t> wbs;
wbs.append(L"work too!");
return 0;
}
[attachment deleted by admin]
Quote from: ollydbg on January 12, 2010, 03:47:36 PM
After that, CC works now !!!!
Great! Thank you very much! :lol:
Quote from: ollydbg on January 12, 2010, 03:47:36 PM
After that, CC works now !!!!
Not for me. :-(
What happens if you just open the TESTING workspace of the CC plugin, activate the STL project, open stl.cpp and uncomment the "ss.". CC does not kick in for me!
And btw: I had that replacement in the
conf file of C::B. Nevertheless it
is missing in the code in trunk.
In the original code the order in how the strings were replaced (when replacing in the whole buffer)
did matter. I don't think it does so in the current version as it is based on the appearance of the tokens, but just to double check: Is that correct?
Quote from: MortenMacFly on January 12, 2010, 06:44:30 PM
Quote from: ollydbg on January 12, 2010, 03:47:36 PM
After that, CC works now !!!!
Not for me. :-(
What happens if you just open the TESTING workspace of the CC plugin, activate the STL project, open stl.cpp and uncomment the "ss.". CC does not kick in for me!
It works here. You can see the screenshot as an attachment.
Quote from: MortenMacFly on January 12, 2010, 06:44:30 PM
In the original code the order in how the strings were replaced (when replacing in the whole buffer) did matter. I don't think it does so in the current version as it is based on the appearance of the tokens, but just to double check: Is that correct?
In the replacement map( wxString Key to wxString Value), I don't think current code has some thing wrong, because each "wxString Key" are different. right? Oh, I can confirm that what you concern won't happen. because when the Tokenizer DoGetToken, they will return a whole "Token string", thus, "_GLIBCXX_BEGIN_NAMESPACE_TR1" and "_GLIBCXX_END_NAMESPACE" are totally different tokens when we are at the last stage of the DoGetToken() function.
Finally, I think the answer is :"it is correct". :D
[attachment deleted by admin]
Quote from: ollydbg on January 13, 2010, 01:00:13 AM
Quote from: MortenMacFly on January 12, 2010, 06:44:30 PM
Quote from: ollydbg on January 12, 2010, 03:47:36 PM
After that, CC works now !!!!
Not for me. :-(
What happens if you just open the TESTING workspace of the CC plugin, activate the STL project, open stl.cpp and uncomment the "ss.". CC does not kick in for me!
It works here. You can see the screenshot as an attachment.
Quote from: MortenMacFly on January 12, 2010, 06:44:30 PM
In the original code the order in how the strings were replaced (when replacing in the whole buffer) did matter. I don't think it does so in the current version as it is based on the appearance of the tokens, but just to double check: Is that correct?
In the replacement map( wxString Key to wxString Value), I don't think current code has some thing wrong, because each "wxString Key" are different. right? Oh, I can confirm that what you concern won't happen. because when the Tokenizer DoGetToken, they will return a whole "Token string", thus, "_GLIBCXX_BEGIN_NAMESPACE_TR1" and "_GLIBCXX_END_NAMESPACE" are totally different tokens when we are at the last stage of the DoGetToken() function.
Finally, I think the answer is :"it is correct". :D
I applied this patch, string parsing normal,
but wstring parsing is not correct.[attachment deleted by admin]
And I found that map, make_pair can parse and display the correct information:
http://forums.next.codeblocks.org/index.php/topic,11784.msg80355.html#msg80355 (http://forums.next.codeblocks.org/index.php/topic,11784.msg80355.html#msg80355)
But this problem still exists:http://forums.next.codeblocks.org/index.php/topic,11784.msg80354.html#msg80354 (http://forums.next.codeblocks.org/index.php/topic,11784.msg80354.html#msg80354)
Oh, look this screenshot.
#include <iostream>
#include <string>
using namespace std;
int main()
{
basic_string<wchar_t> ws;
ws.
return 0;
}
[attachment deleted by admin]
Dammed. I believe I found the REAL reason for the quirks now. blueshake: it may indeed be your real time parse... :-(
What happens:
Assume you have several projects in a WS (like the CC "TESTING" WS). Now if you have project A activated but edit a file with the same name of project B and within a function of the same name as present in project A the real-time parse will update the parser according to the editors name. Hence this may be truncated so what gets updated is the wrong method.
So what happens in my case and why std::string does still not work for make is that the function scope cannot be evaluated as the wrong file is picked and the function markers are invalid. Thus CC will abort and nothing kicks in.
I've made real time parse an option now, however, we should fix this issue!
So: For all of you still struggling of the missing std::string (or alike) completion: Disable "parse while typing" in the CC options but keep in mind that the parser is then only updated upon save! So you need to save the file before you can expect the following to CC:
std::string s;
s. // << CC shall kick in here!
CC works fine for me in any cases now when I have disabled "parse while typing".
I also feel that real-time analysis for editing dulled. After the use of the SVN6082, obviously there is no sense of delay.
QuoteAssume you have several projects in a WS (like the CC "TESTING" WS). Now if you have project A activated but edit a file with the same name of project B and within a function of the same name as present in project A the real-time parse will update the parser according to the editors name. Hence this may be truncated so what gets updated is the wrong method.
hi,morten:
if I remember right,the editor name should be the full name.for your example.if there are two same name files in projectA and projectB.
it should be .\projectA\filename
it should be .\projectB\filenamethe parser should parse the file correctly according the editor file.
Quote from: blueshake on January 14, 2010, 01:47:42 AM
if I remember right,the editor name should be the full name.for your example.if there are two same name files in projectA and projectB.
it should be .\projectA\filename
it should be .\projectB\filename
the parser should parse the file correctly according the editor file.
I think a full file name with full path(such as: C:\projectA\AAA.cpp or C:\projectB\AAA.cpp )is recorded in the filelist of CC.
QuoteI think a full file name with full path(such as: C:\projectA\AAA.cpp or C:\projectB\AAA.cpp )is recorded in the filelist of CC.
haha,that is what I want to express.
Quote from: Loaden on January 13, 2010, 02:24:59 PM
Oh, look this screenshot.
#include <iostream>
#include <string>
using namespace std;
int main()
{
basic_string<wchar_t> ws;
ws.
return 0;
}
@Loaden
This works fine here, rev 6083.
You can see the screen shot below:
[attachment deleted by admin]
where is the option "parse while typiing"?
Quote from: blueshake on January 14, 2010, 02:33:59 AM
where is the option "parse while typiing"?
Menu->settings->Editor->CodeCompletion.
hi,I encouter that the parser can not parse in real-time even I enable "parse while typing".
edit:
update to the latest svn without any change.
Quote from: blueshake on January 14, 2010, 03:10:21 AM
hi,I encouter that the parser can not parse in real-time even I enable "parse while typing".
edit:
update to the latest svn without any change.
Yes, I can confirm this bug.
the reason is simple.
the variable needParse's scope is function scope.when it (needParse) leave the functioin body.it will be destroyed.so it will be false again when the carect is in different line.
Quote from: ollydbg on January 14, 2010, 02:09:35 AM
Quote from: Loaden on January 13, 2010, 02:24:59 PM
Oh, look this screenshot.
#include <iostream>
#include <string>
using namespace std;
int main()
{
basic_string<wchar_t> ws;
ws.
return 0;
}
@Loaden
This works fine here, rev 6083.
You can see the screen shot below:
If you drag the scroll bar prompt window, you will find many non-basic_string <T> function, it seems from iostream.
[attachment deleted by admin]
SVN 6083.
[attachment deleted by admin]
QuoteIf you drag the scroll bar prompt window, you will find many non-basic_string <T> function, it seems from iostream.
you can not use variable name
ws here.because it has been defined in istream.tcc which belong to gcc files.
Note:try another name e.g.
wsss,you will get the answer.
Quote from: blueshake on January 14, 2010, 06:18:32 AM
QuoteIf you drag the scroll bar prompt window, you will find many non-basic_string <T> function, it seems from iostream.
you can not use variable name ws here.because it has been defined in istream.tcc which belong to gcc files.
Note:
try another name e.g. wsss,you will get the answer.
Good! So, this is not a problem. :wink:
Just a reminder:
@morten
This is a big bug, should be fixed soon.
Re: The 12 January 2010 build (6080) is out. (http://forums.next.codeblocks.org/index.php/topic,11844.msg80487.html#msg80487)
Quote from: ollydbg on January 14, 2010, 06:38:29 AM
Quote from: blueshake on January 14, 2010, 06:18:32 AM
QuoteIf you drag the scroll bar prompt window, you will find many non-basic_string <T> function, it seems from iostream.
you can not use variable name ws here.because it has been defined in istream.tcc which belong to gcc files.
Note:
try another name e.g. wsss,you will get the answer.
Good! So, this is not a problem. :wink:
Confirm it! Thanks!
Below code works fine.
#include <iostream>
#include <string>
int main()
{
std::wstring ws;
ws.
return 0;
}
Quote from: blueshake on January 14, 2010, 03:59:41 AM
the reason is simple.
the variable needParse's scope is function scope.when it (needParse) leave the functioin body.it will be destroyed.so it will be false again when the carect is in different line.
I don't get it. m_NeedReparse was used just there. So what's wrong with this piece of code:
Parser* parser = m_NativeParser.GetParserPtr();
bool needReparse = false;
if ( parser && parser->Options().whileTyping
&& ( (event.GetModificationType() & wxSCI_MOD_INSERTTEXT)
|| (event.GetModificationType() & wxSCI_MOD_DELETETEXT) ) )
{
needReparse = true;
}
if (control->GetCurrentLine() != m_CurrentLine)
{
if (parser && needReparse)
parser->Reparse(editor->GetFilename());
else
FindFunctionAndUpdate(control->GetCurrentLine());
}
It will trigger the re-parse correctly in the case a parser is present, the option is enabled and a char was inserted/deleted.
So...?! (I am a bit sick, so probably you should explain
slowly... ;-)).
Quote from: ollydbg on January 14, 2010, 06:46:52 AM
@morten
This is a big bug, should be fixed soon.
Re: The 12 January 2010 build (6080) is out. (http://forums.next.codeblocks.org/index.php/topic,11844.msg80487.html#msg80487)
Done in my local copy. Will commit in a while... probably after
blueshake answered the other question which may require some modifications, too.
QuoteI don't get it. m_NeedReparse was used just there. So what's wrong with this piece of code:
see the codes below,in the new codes,it declare a new variable
needReparse ,not
m_NeedReparse.
Parser* parser = m_NativeParser.GetParserPtr();
bool needReparse = false;
if ( parser && parser->Options().whileTyping
&& ( (event.GetModificationType() & wxSCI_MOD_INSERTTEXT)
|| (event.GetModificationType() & wxSCI_MOD_DELETETEXT) ) )
{
needReparse = true;
}
if (control->GetCurrentLine() != m_CurrentLine)
{
if (parser && needReparse)
parser->Reparse(editor->GetFilename());
else
FindFunctionAndUpdate(control->GetCurrentLine());
}
maybe this will help a little.
Index: src/plugins/codecompletion/codecompletion.cpp
===================================================================
--- src/plugins/codecompletion/codecompletion.cpp (revision 6083)
+++ src/plugins/codecompletion/codecompletion.cpp (working copy)
@@ -2085,17 +2085,24 @@
}
Parser* parser = m_NativeParser.GetParserPtr();
- bool needReparse = false;
+ //bool needReparse = false;
if ( parser && parser->Options().whileTyping
&& ( (event.GetModificationType() & wxSCI_MOD_INSERTTEXT)
|| (event.GetModificationType() & wxSCI_MOD_DELETETEXT) ) )
{
- needReparse = true;
+ //needReparse = true;
+ m_NeedReparse = true;
}
if (control->GetCurrentLine() != m_CurrentLine)
{
- if (parser && needReparse)
- parser->Reparse(editor->GetFilename());
+
+ if (parser && m_NeedReparse)
+ {
+ m_NeedReparse = false;
+ parser->Reparse(editor->GetFilename());
+ }
else
FindFunctionAndUpdate(control->GetCurrentLine());
}
Index: src/plugins/codecompletion/codecompletion.h
===================================================================
--- src/plugins/codecompletion/codecompletion.h (revision 6083)
+++ src/plugins/codecompletion/codecompletion.h (working copy)
@@ -135,7 +135,7 @@
int m_ActiveCalltipsNest;
bool m_IsAutoPopup;
-
+ bool m_NeedReparse;
wxChoice* m_Function;
wxChoice* m_Scope;
FunctionsScopeVec m_FunctionsScope;
NOTE:
the patch is used to show what changed(or explain what I try to say.please do not apply it) :wink:
To make it clear, why the current code does not work:
needReparse is set to true whenever text is inserted or deleted, but the reparsing is only triggered if we leave the current line.
This does normally (never ?) happen inside the same event, so we have to remember whether a reparse is needed, either with a member-variable or a static local variable.
Quote from: jens on January 14, 2010, 02:27:28 PM
This does normally (never ?) happen inside the same event, so we have to remember whether a reparse is needed, either with a member-variable or a static local variable.
Dammed. Now I got the point. Ok... I'll take care...
Me should not work when being sick. :?
Quote from: MortenMacFly on January 14, 2010, 04:31:47 PM
Me should not work when being sick. :?
Nobody should.
I hope you feel better soon.
This is what Visual c++'s code completion do in the feature:
http://blogs.msdn.com/vcblog/archive/2009/08/12/tag-parsing-c.aspx
I think a variable in Tokenizer class can be removed, because it is never used any more.
bool m_IsOperator;
BTW: comparing with the "operator" keyword is done in the ParserThread class instead of Tokenizer class.
Edit
Also, this function is never used in Tokenizer, we use another function.
inline const wxString& ThisOrReplacement(const wxString& str) const
{
ConfigManagerContainer::StringToStringMap::const_iterator it = s_Replacements.find(str);
if (it != s_Replacements.end())
return it->second;
return str;
};
So, it can be cleaned up.
QuoteI think a variable in Tokenizer class can be removed, because it is never used any more.
Code:
bool m_IsOperator;
BTW: comparing with the "operator" keyword is done in the ParserThread class instead of Tokenizer class.
@ollydbg
it was used here in nativeparser.cpp
if (!token)
{
if (s_DebugSmartSense)
Manager::Get()->GetLogManager()->DebugLog(_T("FindAIMatches() Token is NULL?!"));
continue;
}
// ignore operators
if (token->m_IsOperator)
continue;
// enums children (enumerators), are added by default
if (token->m_TokenKind == tkEnum)
{
// insert enum type
result.insert(id);
Quote from: blueshake on January 17, 2010, 02:40:20 AM
QuoteI think a variable in Tokenizer class can be removed, because it is never used any more.
Code:
bool m_IsOperator;
BTW: comparing with the "operator" keyword is done in the ParserThread class instead of Tokenizer class.
@ollydbg
it was used here in nativeparser.cpp
if (!token)
{
if (s_DebugSmartSense)
Manager::Get()->GetLogManager()->DebugLog(_T("FindAIMatches() Token is NULL?!"));
continue;
}
// ignore operators
if (token->m_IsOperator)
continue;
// enums children (enumerators), are added by default
if (token->m_TokenKind == tkEnum)
{
// insert enum type
result.insert(id);
No, There is a member m_IsOperator in the Token class. so does in Tokenizer class.
test codes:#include <iostream>
using namespace std;
int abc(int aa)
{
int bb;
aa----------------------not work here.
return 0;
}
int main()
{
cout << "Hello world!" << endl;
return 0;
}issue:the cc can not do codecompletion for variable
aareason:I suspect that the function arguments were not parsed.
see the output log.yoou can see that only one temp token bb was added.
QuoteParseLocalBlock() Block:
int bb;
aa
ParseLocalBlock() Local tokens:
ParseLocalBlock() + int bb parent =
AI() AI enter, actual_search: " aa"
AI() =========================================================
And see the output log of work version,two temp tokens(aa and bb) were added.
QuoteParseLocalBlock() Block:
int bb;
aa
ParseLocalBlock() Local tokens:
ParseLocalBlock() + int aa parent =
ParseLocalBlock() + int bb parent =
AI() AI enter, actual: " aa"
AI() =========================================================
#include <iostream>
#include <map>
#include <string>
int main()
{
typedef std::map<int, std::string> TestMap;
TestMap testMap;
// testMap. // not work!
std::map<int, std::string> m;
m.insert(1, "Hello World!"); // work fine.
return 0;
}
[attachment deleted by admin]
Quotestd::map<int, std::string> m;
m.insert(1, "Hello World!"); // work fine.
not work for me.
I search the tokenstree and get nothing.
Quote from: blueshake on January 17, 2010, 01:07:28 PM
Quotestd::map<int, std::string> m;
m.insert(1, "Hello World!"); // work fine.
not work for me.
I search the tokenstree and get nothing.
[attachment deleted by admin]
test code：
int abc(int aaaaa)
{
int bb;
aaa
return 0;
}
int main()
{
cout << "Hello world!" << endl;
return 0;
}
In a old version of C::B, it works!
MarkItemsByAI()
ParseUsingNamespace() Parse file scope for "using namespace"
ParseFunctionArguments() Parse function arguments
FindCurrentFunctionStart() Current function: int abc(int aaaaa) (at line 1)
GenerateResultSet() search 'abc', parent='Global namespace (id:0, type:(null)), isPrefix=0'
ParseFunctionArguments() + Function match: abc
ParseFunctionArguments() Parsing arguments: "int aaaaa;"
ParseLocalBlock() Parse local block
ParseLocalBlock() Block:
int bb;
aaa
ParseLocalBlock() Local tokens:
ParseLocalBlock() + int aaaaa parent =
ParseLocalBlock() + int bb parent =
AI() AI enter, actual: " aaa"
AI() =========================================================
In the current C::B, failed. see the log:
MarkItemsByAI()
ParseUsingNamespace() Parse file scope for "using namespace"
ParseLocalBlock() Parse local block
FindCurrentFunctionStart() Looking for tokens in 'C:\cb\testforum\main.cpp'
FindCurrentFunctionStart() Found 2 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main()', tF='C:\cb\testforum\main.cpp', tStart=9, tEnd=12
FindCurrentFunctionStart() Function out of bounds: tN='int main()', tF='C:\cb\testforum\main.cpp', tStart=9, tEnd=12, line=5 (size_t)line=5
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int abc(int aaaaa)', tF='C:\cb\testforum\main.cpp', tStart=2, tEnd=7
FindCurrentFunctionStart() Current function: 'int abc(int aaaaa)' (at line 1)
FindCurrentFunctionStart() Namespace='', proc='abc' (returning 20)
ParseLocalBlock() Block:
int bb;
aa
ParseLocalBlock() Local tokens:
ParseLocalBlock() + int bb parent =
AI() AI enter, actual_search: " aa"
AI() =========================================================
So, I will check why the function parameters were not added.....
Quote from: Loaden on January 17, 2010, 12:53:04 PM
#include <iostream>
#include <map>
#include <string>
int main()
{
typedef std::map<int, std::string> TestMap;
TestMap testMap;
// testMap. // not work!
std::map<int, std::string> m;
m.insert(1, "Hello World!"); // work fine.
return 0;
}
@Loaden
you can not typedef something in the function body.The reason is not clear for me,maybe ollydbg or morten can release some answers. :D
Quite strange. See the function below:
// Here, we collect the "using namespace XXXX" directives
// Also, we locate the current caret in which function, then, add the function parameters to Token trie
// Also, the variables in the function body( local block ) was add to the Token trie
size_t NativeParser::MarkItemsByAI(TokenIdxSet& result, bool reallyUseAI, bool noPartialMatch, bool caseSensitive, int caretPos)
{
if (s_DebugSmartSense)
Manager::Get()->GetLogManager()->DebugLog(F(_T("MarkItemsByAI()")));
result.clear();
cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
if (!ed)
return 0;
if (!m_Parser.Done())
Manager::Get()->GetLogManager()->DebugLog(_T("C++ Parser is still parsing files..."));
else
{
// remove old temporaries
m_Parser.GetTokens()->FreeTemporaries();
m_Parser.GetTempTokens()->Clear();
// find "using namespace" directives in the file
TokenIdxSet search_scope;
ParseUsingNamespace(ed, search_scope, caretPos);
// parse function's arguments
ParseFunctionArguments(ed, caretPos);
// parse current code block (from the start of function up to the cursor)
ParseLocalBlock(ed, caretPos);
if (!reallyUseAI)
{
// all tokens, no AI whatsoever
TokensTree* tokens = m_Parser.GetTokens();
for (size_t i = 0; i < tokens->size(); ++i)
result.insert(i);
return result.size();
}
// we have correctly collected all the tokens, so we will do the artificial intelligence search
return AI(result, ed, wxEmptyString, noPartialMatch, caseSensitive, &search_scope, caretPos);
}
return 0;
}
So, the ParseFunctionArguments(ed, caretPos); should be called. But see in the ParseFunctionArguments body, there is a log out put :
bool NativeParser::ParseFunctionArguments(cbEditor* ed, int caretPos)
{
if (!ed)
return false;
if (m_Parser.Done())
return false;
if (s_DebugSmartSense)
Manager::Get()->GetLogManager()->DebugLog(_T("ParseFunctionArguments() Parse function arguments"));
TokenIdxSet proc_result;
if (FindCurrentFunctionToken(ed, proc_result, caretPos) != 0)
{
for (TokenIdxSet
But I can't see any text about "ParseFunctionArguments() Parse function arguments" in the debug log output.... Why?
hi,guys.
I found the bug
in the ParseFunctionArguments
should be so
if (!m_Parser.Done())
return false;
not so.
if (m_Parser.Done())
return false;
Quote from: blueshake on January 17, 2010, 02:33:43 PM
hi,guys.
I found the bug
in the ParseFunctionArguments
should be so
if (!m_Parser.Done())
return false;
not so.
if (m_Parser.Done())
return false;
Great! Why the "!" is missing........It seems we haven't change this function.
Edit:It is a typo in rev 6058. :D
Quote from: ollydbg on January 17, 2010, 02:36:07 PM
Great! Why the "!" is missing........It seems we haven't change this function.
My fault. I was removing the artifacts from the past where there used to be a parser per project. So I changed all references to "per project parser" to the global none and obviously missed the !" there. Sorry. Will fix asap...
Quote from: blueshake on January 17, 2010, 02:14:25 PM
Quote from: Loaden on January 17, 2010, 12:53:04 PM
#include <iostream>
#include <map>
#include <string>
int main()
{
typedef std::map<int, std::string> TestMap;
TestMap testMap;
// testMap. // not work!
std::map<int, std::string> m;
m.insert(1, "Hello World!"); // work fine.
return 0;
}
@Loaden
you can not typedef something in the function body.The reason is not clear for me,maybe ollydbg or morten can release some answers. :D
#include <iostream>
#include <map>
#include <string>
typedef std::map<int, std::string> TestMap;
class A
{
public:
void Test()
{
TestMap2 t2;
t2.in // works here too.
}
private:
typedef std::map<int, std::string> TestMap2;
}
int main()
{
TestMap testMap;
testMap.i // ok, work now.
return 0;
}
[attachment deleted by admin]
New bug:
#include <iostream>
int main()
{
// std::cou // not work!
std::endl // work here.
return 0;
}
[attachment deleted by admin]
There's a small problem.
[attachment deleted by admin]
Quote from: Loaden on January 17, 2010, 04:40:38 PM
There's a small problem.
That's not a problem, that's by design.
Quote#include <iostream>
int main()
{
// std::cou // not work!
std::endl // work here.
return 0;
}
where is the definition of std::cout???
Quote from: blueshake on January 18, 2010, 03:06:52 AM
where is the definition of std::cout???
Directly in
iostream:
extern istream cin; ///< Linked to standard input
extern ostream cout; ///< Linked to standard output
extern ostream cerr; ///< Linked to standard error (unbuffered)
extern ostream clog; ///< Linked to standard error (buffered)
And yes: It's "gone". ?!
In my opinion: In the parserThread DoParse function, when it meet the "extern" keyword, the parser just skip to the the ";".
Quote from: ollydbg on January 18, 2010, 06:55:36 AM
In my opinion: In the parserThread DoParse function, when it meet the "extern" keyword, the parser just skip to the the ";".
right.that is why I ask where is the real definition.if it is just so,we need to do some handle about extern.
Quote from: ollydbg on January 18, 2010, 06:55:36 AM
In my opinion: In the parserThread DoParse function, when it meet the "extern" keyword, the parser just skip to the the ";".
No, the code is question is as follows:
else if (token==ParserConsts::kw_extern)
{
// check for "C"
m_Str = m_Tokenizer.GetToken();
if (m_Str==ParserConsts::kw_C)
{
m_Tokenizer.GetToken(); // "eat" {
DoParse(); // time for recursion ;)
}
else
{
// do nothing, just skip keyword "extern", otherwise uncomment:
//SkipToOneOfChars(ParserConsts::semicolon); // skip externs
}
m_Str.Clear();
}
As you see: Really only "extern" is skipped, the rest is parsed as usual.
m_Str = m_Tokenizer.GetToken();
if (m_Str==ParserConsts::kw_C)
{
m_Tokenizer.GetToken(); // "eat" {
DoParse(); // time for recursion ;)
}
else
{
// do nothing, just skip keyword "extern", otherwise uncomment:
//SkipToOneOfChars(ParserConsts::semicolon); // skip externs
}
m_Str.Clear();
it seems I get the reason.
e.g. extern int aa;
when we do this.
m_Str = m_Tokenizer.GetToken();
now the m_Str is int.
but here we clear the m_Str again.
m_Str.Clear();
so the m_Str is empty.I think this is why the cout can not be parsed correctly.
solution :
comment this statement may work.
//m_Str.Clear();
Quote from: Loaden on January 17, 2010, 04:32:08 PM
New bug:
#include <iostream>
int main()
{
// std::cou // not work!
std::endl // work here.
return 0;
}
patch for it.
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 6089)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -524,7 +524,7 @@
else if (token==ParserConsts::kw_extern)
{
// check for "C"
- m_Str = m_Tokenizer.GetToken();
+ m_Str = m_Tokenizer.PeekToken();
if (m_Str==ParserConsts::kw_C)
{
m_Tokenizer.GetToken(); // "eat" {
see the screen shot.
[attachment deleted by admin]
Quote from: blueshake on January 18, 2010, 09:00:15 AM
patch for it.
Index: src/plugins/codecompletion/parser/parserthread.cpp
// check for "C"
- m_Str = m_Tokenizer.GetToken();
+ m_Str = m_Tokenizer.PeekToken();
if (m_Str==ParserConsts::kw_C)
{
m_Tokenizer.GetToken(); // "eat" {
Be careful: In that case not the "
{" is "eaten" in the case of
extern C {...} statements, but the "
C". So your patch will work for the extern cout thing, but will break
extern C {...}.
This maybe corrected by issuing "
m_Tokenizer.GetToken();" twice in the
if clause, the fiorst time for "
C", the second time for the "
{".
hi,morten:
what about this way.
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 6089)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -534,6 +534,7 @@
{
// do nothing, just skip keyword "extern", otherwise uncomment:
//SkipToOneOfChars(ParserConsts::semicolon); // skip externs
+ m_Tokenizer.UngetToken();
}
m_Str.Clear();
}
Quote from: blueshake on January 18, 2010, 09:09:13 AM
hi,morten:
what about this way.
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 6089)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -534,6 +534,7 @@
{
// do nothing, just skip keyword "extern", otherwise uncomment:
//SkipToOneOfChars(ParserConsts::semicolon); // skip externs
+ m_Tokenizer.UngetToken();
}
m_Str.Clear();
}
Work now! :P
Quote from: blueshake on January 18, 2010, 09:09:13 AM
what about this way.
...I'll try.
BTW: I was in fact thinking about having another flag for the token to declare it as "extern" (similar to
m_IsConst). This would help to e.g. overwrite the "content" in the case you find the true definition / implementation. In addition the tooltip could show "extern" if only the "extern" declaration is found, indicating that the implementation might not be known (as it is in a binary library, for example).
Quote from: MortenMacFly on January 18, 2010, 09:47:40 AM
Quote from: blueshake on January 18, 2010, 09:09:13 AM
what about this way.
...I'll try.
BTW: I was in fact thinking about having another flag for the token to declare it as "extern" (similar to m_IsConst). This would help to e.g. overwrite the "content" in the case you find the true definition / implementation. In addition the tooltip could show "extern" if only the "extern" declaration is found, indicating that the implementation might not be known (as it is in a binary library, for example).
Good idea! But it seems there are too many bool variables in the Token class.
bool m_IsOperator;
bool m_IsLocal; // found in a local file?
bool m_IsTemp; // if true, the tree deletes it in FreeTemporaries()
bool m_IsConst; // the member method is const (yes/no)As we build the C::B in the "debug" mode, then strip the debug information. I think one bool variable occupy 4 BYTE in the memory.
I'm not sure a enum variable(combine all the state in one variable) is better??
I have deleted cb configuration files. Next run cb creates these files with default values.
I've noticed that tokens replacement list is extended. See attacment.
std::string s1; s1. now works fine
As i understand, if you patched your installation to latest nighty, configuration files are not patched at first run.
[attachment deleted by admin]
Quote from: sbezgodov on January 18, 2010, 10:50:50 AM
I have deleted cb configuration files. Next run cb creates these files with default values.
I've noticed that tokens replacement list is extended. See attacment.
std::string s1; s1. now works fine
As i understand, if you patched your installation to latest nighty, configuration files are not patched at first run.
work fine here.Make sure that you have include the string file. :D
see my attachment.
[attachment deleted by admin]
Quote from: sbezgodov on January 18, 2010, 10:50:50 AM
I have deleted cb configuration files. Next run cb creates these files with default values.
I've noticed that tokens replacement list is extended. See attacment.
std::string s1; s1. now works fine
As i understand, if you patched your installation to latest nighty, configuration files are not patched at first run.
Yes, you need edit the "default.conf" file, and add the replacement rules.
<TOKEN_REPLACEMENTS>
<ssmap>
<_GLIBCXX_BEGIN_NAMESPACE>
<![CDATA[+namespace]]>
</_GLIBCXX_BEGIN_NAMESPACE>
<_GLIBCXX_BEGIN_NAMESPACE_TR1>
<![CDATA[-namespace tr1 {]]>
</_GLIBCXX_BEGIN_NAMESPACE_TR1>
<_GLIBCXX_BEGIN_NESTED_NAMESPACE>
<![CDATA[+namespace]]>
</_GLIBCXX_BEGIN_NESTED_NAMESPACE>
<_GLIBCXX_END_NAMESPACE>
<![CDATA[}]]>
</_GLIBCXX_END_NAMESPACE>
<_GLIBCXX_END_NAMESPACE_TR1>
<![CDATA[}]]>
</_GLIBCXX_END_NAMESPACE_TR1>
<_GLIBCXX_END_NESTED_NAMESPACE>
<![CDATA[}]]>
</_GLIBCXX_END_NESTED_NAMESPACE>
<_GLIBCXX_STD>
<![CDATA[std]]>
</_GLIBCXX_STD>
</ssmap>
</TOKEN_REPLACEMENTS>
Quote from: ollydbg on January 18, 2010, 09:55:24 AM
I'm not sure a enum variable(combine all the state in one variable) is better??
In terms of memory footprint: yes. In terms of logic: the boolean field have nothing in common really. So combining them logically makes no sense. So a default enum would be enough.