Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Is it possible for the parser to support newlib prototypes?
Huki:
--- Quote from: ollydbg on September 10, 2014, 05:05:32 pm ---Oh, I just found that the below test works OK for showing the call tip, see the "public" key word.
--- Code: ---class AAA
{
public:
AAA(int a){;}
int m_b;
};
AAA(8);
--- End code ---
:D :D
--- End quote ---
Ahah.. :P Yep, that works for me too.
BTW, now I also tested my note about semi-colon:
--- Quote ---I think Alpha's patch was trying to get calltips for:
--- Code: ---wxStaticText static(|
--- End code ---
Though I'm not sure if it can work, because the variable "static" in the above code won't be parsed unless semi-colon is typed, right?
--- End quote ---
See the code in DoParse(): if we peek a "(" or a ";", we parse the variable.
--- Code: --- else if ( (peek == ParserConsts::semicolon)
|| ( ( m_Options.useBuffer
&& (peek.GetChar(0) == ParserConsts::opbracket_chr) )
&& (!m_Str.Contains(ParserConsts::dcolon)) ) )
{
if ( !m_Str.IsEmpty()
&& ( wxIsalpha(token.GetChar(0))
|| (token.GetChar(0) == ParserConsts::underscore_chr) ) )
{
if (m_Options.handleVars)
{
Token* newToken = DoAddToken(tkVariable, token, m_Tokenizer.GetLineNumber());
if (newToken && !m_TemplateArgument.IsEmpty())
ResolveTemplateArgs(newToken);
}
else
SkipToOneOfChars(ParserConsts::semicolonclbrace, true, true);
}
}
--- End code ---
The current code is already checking for the opbracket, but there seem to be some problems:
--- Code: ---class AAA
{
public:
AAA(int a){;}
int m_b;
};
AAA bbb( // I don't get the constructor calltip
--- End code ---
EDIT: removed attachments.
Alpha:
--- Quote from: ollydbg on September 10, 2014, 05:05:32 pm ---Oh, I just found that the below test works OK for showing the call tip, see the "public" key word.
--- End quote ---
Sorry, should I have mentioned earlier. I filtered out non-visible ctors to avoid the annoying wxString(int) and similar (private ctors are almost never used, to my knowledge).
ollydbg:
--- Quote from: Huki on September 10, 2014, 05:31:52 pm ---The current code is already checking for the opbracket, but there seem to be some problems:
--- Code: ---class AAA
{
public:
AAA(int a){;}
int m_b;
};
AAA bbb( // I don't get the constructor calltip
--- End code ---
EDIT: removed attachments.
--- End quote ---
In my opinion, the "variable pattern" can only be recognized as: "AAA BBB;" or "AAA BBB CCC" or "AAA BBB, CCC".
AAA, BBB, CCC are all kinds of lexeme.
But the pattern like "AAA BBB(...);" are recognized as functions.
If we see "AAA BBB(...)" we don't know it is a variable or a function. :) That's the reason of this call tip failure I think.
I will check the code now.
Huki:
--- Quote from: Alpha on September 10, 2014, 06:02:28 pm ---
--- Quote from: ollydbg on September 10, 2014, 05:05:32 pm ---Oh, I just found that the below test works OK for showing the call tip, see the "public" key word.
--- End quote ---
Sorry, should I have mentioned earlier. I filtered out non-visible ctors to avoid the annoying wxString(int) and similar (private ctors are almost never used, to my knowledge).
--- End quote ---
Yes, thanks, that should be the expected behavior too. I guess ollydbg and I were getting a little forgetful.. ;)
--- Quote from: Huki on September 10, 2014, 05:31:52 pm ---BTW, now I also tested my note about semi-colon:
[...]
--- End quote ---
Today I checked it and it's clear now. A code like AAA bbb(...) can be either a function declaration, or a class variable initialized with a constructor. So how do we find out which one it is? Technically the class variable won't have type info in the arguments, eg:
--- Code: ---AAA bbb(int a); // function declaration
AAA bbb(a); // variable of class AAA
--- End code ---
But our CC plugin follows a much simpler method: if the code is found in the global namespace, "handle_functions" is true, and it is parsed like a function declaration. Inside a local block, "handle_functions" is false and it is parsed like a variable. So with the current code we can get the calltip:
--- Code: ---class AAA
{
public:
AAA(int a){;}
int m_b;
};
void func()
{
AAA bbb( // shows calltip for constructor AAA::AAA()
}
--- End code ---
It's probably enough for most purposes, so for now I'll leave it like this.
ollydbg:
--- Quote from: Huki on September 11, 2014, 07:21:13 am ---
--- Quote from: Alpha on September 10, 2014, 06:02:28 pm ---
--- Quote from: ollydbg on September 10, 2014, 05:05:32 pm ---Oh, I just found that the below test works OK for showing the call tip, see the "public" key word.
--- End quote ---
Sorry, should I have mentioned earlier. I filtered out non-visible ctors to avoid the annoying wxString(int) and similar (private ctors are almost never used, to my knowledge).
--- End quote ---
Yes, thanks, that should be the expected behavior too. I guess ollydbg and I were getting a little forgetful.. ;)
--- End quote ---
Yes, I can't remember anything about this. ;)
--- Quote ---
--- Quote from: Huki on September 10, 2014, 05:31:52 pm ---BTW, now I also tested my note about semi-colon:
[...]
--- End quote ---
Today I checked it and it's clear now. A code like AAA bbb(...) can be either a function declaration, or a class variable initialized with a constructor. So how do we find out which one it is? Technically the class variable won't have type info in the arguments, eg:
--- Code: ---AAA bbb(int a); // function declaration
AAA bbb(a); // variable of class AAA
--- End code ---
But our CC plugin follows a much simpler method: if the code is found in the global namespace, "handle_functions" is true, and it is parsed like a function declaration. Inside a local block, "handle_functions" is false and it is parsed like a variable. So with the current code we can get the calltip:
--- Code: ---class AAA
{
public:
AAA(int a){;}
int m_b;
};
void func()
{
AAA bbb( // shows calltip for constructor AAA::AAA()
}
--- End code ---
It's probably enough for most purposes, so for now I'll leave it like this.
--- End quote ---
Correct, I just review the code, and I get the same conclusion. It comes from this code:
--- Code: --- (peek == ParserConsts::semicolon)
|| ( ( m_Options.useBuffer
&& (peek.GetChar(0) == ParserConsts::opbracket_chr) )
&& (!m_Str.Contains(ParserConsts::dcolon)) ) )
--- End code ---
m_Options.useBuffer means we are parsing function body, and peek.GetChar(0) == ParserConsts::opbracket_chr means we find a pattern like "AAA BBB(", so this is a variable only in function bodies. Not easy to handle those issue, since they need semantic information.
EDIT
I will add some comments about those patterns in the source code.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version