Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

code completion enhancement request

<< < (2/2)

p2rkw:

--- Code: ---for (auto foo : container)
--- End code ---
Keep in mind that instead of container there might be expression. And "auto" have different meaning in c++03.

As you can see here: http://en.cppreference.com/w/cpp/language/range-for , loop declaration:

--- Code: ---for ( range_declaration : range_expression) loop_statement
--- End code ---
is equals to

--- Code: ---    auto && __range = range_expression ;
    auto __begin = __range.begin(); // or begin(__range);
    auto __end = __range.end();      // or end(__range);
    for (;__begin != __end; ++__begin) {
        range_declaration = *__begin;
        loop_statement
    }
--- End code ---

and declaration
--- Code: ---auto foo = expression
--- End code ---
is logically equals to
--- Code: ---decltype(expression) foo = expression
--- End code ---

To implement decltype parser might use NativeParser::AI to find out type of expression (all required tokens should be already in tree), but actually ParserThread doesn't have access to NativeParser object.

p2rkw:
I have tried to implement this feature, result here: http://imgur.com/WTWdDPz
but it seems CC cant find "operator*" in std::vector::const_iterator, so it doesn't work for std::vector and probably for all templates.

@developers: can m_NativeParser pointer be pass down to ParserThread?

ollydbg:

--- Quote from: p2rkw on March 30, 2013, 03:55:34 am ---@developers: can m_NativeParser pointer be pass down to ParserThread?

--- End quote ---
Why do you want to do that, you want let the ParserThread to access NativeParser class?

I think the control level is: (the most left is the most hight control level)

CodeCompletion class -> NativeParser -> Parser -> ParserThread -> Tokenizer

p2rkw:

--- Quote ---CodeCompletion class -> NativeParser -> Parser -> ParserThread -> Tokenizer
--- End quote ---
Thats true, but:
source file is parsed in ParserThread, and TokenTree is build there. So what can parser do when "auto" or "decltype" token occurs?
My idea was to detect real type of variable defined as "decltype" using  NativeParserBase::ResolveActualType or somethin like that. All tokens required to detect real type of "auto" variable or function probably will be already in tree.

Lets assume you have access to nativeParser in ParserThread, so you can write something like this in DoParse:

--- Code: ---if(token == ParserConsts::dectype)
{
  m_Tokenizer.GetToken(); // eat "decltype"
  m_Tokenizer.GetToken(); // eat "("
  string type = m_Tokenizer.GetToken();
  //release lock here
  TokenIdxSet result;
  nativeParser->resolveActualType(m_tree, type, ..., result) // or AI( ..., type, result)
  //lock again
  Token *newToken = DoAddToken(tkVariable, token, smallTokenizer.GetLineNumber());
  newToken->m_FullType = tree[result.begin()]->m_FullType;
}

--- End code ---

ollydbg:
I understand your idea.

--- Code: ---size_t NativeParserBase::ResolveActualType(TokenTree*         tree,
                                           wxString           searchText,
                                           const TokenIdxSet& searchScope,
                                           TokenIdxSet&       result)

--- End code ---
See the third parameter, it is the searchScope, which is a C++ exposed scope(context). It can be introduced by
1, using directive
2, class inheritance
3, scope exposed in its include files
4, other cases
So, how do you get them?

The dirty thing is C++ grammar is context sensitive, it is hard to solve which type when the Parserthread meet a decltype.

Another thing is:
Is it possible to introduce a Token, which has type string named "undefined" or "lasy", then when NativeParser need to show tooltip or code suggestion, it can solve them. (I mean solve the types later when needed)

Final thought, type solving is related to semantic check stage, but our CC's parser mostly do a syntax check, so if we need precise information, a full parser (Clang or GCC) is needed.

Navigation

[0] Message Index

[*] Previous page