Difference between revisions of "Code::Completion Rewrite"

From Code::Blocks
Line 36: Line 36:
 
=== Process ===
 
=== Process ===
 
==== Code::SymbolTable ====
 
==== Code::SymbolTable ====
 +
 +
There will be 3 symbol lists:
 +
# global namespace
 +
# local scope
 +
# class scope
 +
 +
Here's the current data proposal:
 +
 
  class symbol
 
  class symbol
 
  {
 
  {
 
     string name;              // name of the symbol
 
     string name;              // name of the symbol
     int    id;                // Id of the symbol, should be unique in the project
+
     int    id;                // Id of the symbol, should be unique in the workspace
     int    file_id;          // if od file where the symbol has been declared
+
     int    file_id;          // Id of file where the symbol has been declared
 
     int    filepos_begin;    // Position where declaration of the symbol starts
 
     int    filepos_begin;    // Position where declaration of the symbol starts
 
     int    filepos_end;      // Position where declaration of the symbol ends
 
     int    filepos_end;      // Position where declaration of the symbol ends
 
     int    type;              // Type of the symbol: macro / class / typedef / variable / function
 
     int    type;              // Type of the symbol: macro / class / typedef / variable / function
     int    modifiers;        // Bitfield used to mark some estra properties of symbol like that it is static or inline
+
     flags  modifiers;        // Bitfield used to mark some estra properties of symbol
     int    value_type_id;    // Id of symbol which represents c++ type of current symbol (like type of variable or type of returned value from function)
+
                              // like that it is static or inline
 +
     int    value_type_id;    // Id of symbol which represents c++ type of current symbol
 +
                              // (like type of variable or type of returned value from function)
 
     int    extra_type_id;    // Extra type used in some cases
 
     int    extra_type_id;    // Extra type used in some cases
 
     list  children;          // List of child elements of this symbol (members in class etc)
 
     list  children;          // List of child elements of this symbol (members in class etc)
     list  extra_lists[3];    // Some extra lists which can provide additional symbols depending on type of current
+
     list  extra_lists[3];    // See table below
                              // symbol - like list of base classes or list of template arguments, maybe we could give
 
                              // more than 3 lists, but I didn't found any reason for that now.
 
 
     map    extra_values;      // int -> string map which can keep some extra data
 
     map    extra_values;      // int -> string map which can keep some extra data
 
  }
 
  }
 +
 +
class list_entry
 +
{
 +
    int    symbol_id;        // ID of the symbol referenced
 +
    int    storage_class;    // Storage class of the symbol (private/protected/public)
 +
}
 +
 +
Explanation of symbol::extra_lists[]
 +
{| border="1" cellpadding="3" cellspacing="0" style="border: 1px solid gray; border-collapse: collapse;"
 +
|- style="background: #ececec; border: 1px solid gray;"
 +
! type
 +
! modifiers
 +
! value_type_id
 +
! extra_type
 +
! children
 +
! extra_lists[0]
 +
! extra_lists[1]
 +
! extra_lists[2]
 +
|-
 +
 +
|-
 +
| namespace
 +
|
 +
|
 +
|
 +
| declarations in namespace
 +
|"using" namespaces
 +
|
 +
|
 +
|-
 +
 +
|-
 +
| class / struct / union
 +
|
 +
|
 +
|
 +
| members of class
 +
| base classes
 +
| template args
 +
| friends of class
 +
|-
 +
 +
|-
 +
| variable
 +
| extern, static, volatile, const
 +
| type of variable
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
 +
|-
 +
| function
 +
| static, inline, const ...
 +
| returned value
 +
|
 +
| arguments
 +
| template arguments
 +
|
 +
|
 +
|-
 +
 +
|-
 +
| typedef
 +
| pointer, array, reference, pointer_to_member
 +
| base type
 +
| type of class in pointer_to_member
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
 +
|-
 +
| enum
 +
|
 +
|
 +
|
 +
| items in enum
 +
|
 +
|
 +
|
 +
|-
 +
 +
|-
 +
| enum item
 +
|
 +
|
 +
| id of enum
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
 +
|-
 +
| macro
 +
|
 +
|
 +
|
 +
| macro parts
 +
|
 +
|
 +
|
 +
|-
 +
 +
|-
 +
| macro part
 +
| arg_to_string, va_args
 +
| number of arg or -1
 +
|
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
 +
|}
 +
 +
Comments:
 +
* Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.
 +
* Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.
 +
 +
 +
Questions:
 +
* why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?
  
 
==== Code::Completion ====
 
==== Code::Completion ====

Revision as of 16:07, 11 March 2008

Background

The current Code::Completion plug-in has some flaws, and is currently development frozen. The current plug-in lacks full support for:

  1. function and class templates
  2. default arguments in some cases
  3. some of the more complicated c++ mucky business

Current Effort

Structure

The current C::C is a monolithic library of features, which could be de-coupled and split up for use in multiple plugins, providing extra functionality and flexibility in the future. Therefore, I propose the C::C be broken up into the following components:

  • Code::SymbolTable
    • Provide a list of valid symbols in the workspace, along with relevant scope information
  • Code::Completion
    • Provide Auto-complete features
  • Code::SymbolOutline
    • Provide Symbol browser, find symbol, function jump features
  • Code::Refactoring
    • Provide code refactoring features
  • Code::Documentation
    • Provide automatic code generation features

Purpose Statement

Code::Completion

The current Code::Completion plugin is outdated, and needs a complete rewrite. The purpose of the Code::Completion plugin is thus:

  • Provide a list of likely symbols in the current scope as possible solutions to the current symbol.
  • Provide function tooltips
    • Parameter list
    • Relevant documentation
  • Provide completion features for class constructors
  • Provide completion features for initializer lists

Process

Code::SymbolTable

There will be 3 symbol lists:

  1. global namespace
  2. local scope
  3. class scope

Here's the current data proposal:

class symbol
{
    string name;              // name of the symbol
    int    id;                // Id of the symbol, should be unique in the workspace
    int    file_id;           // Id of file where the symbol has been declared
    int    filepos_begin;     // Position where declaration of the symbol starts
    int    filepos_end;       // Position where declaration of the symbol ends
    int    type;              // Type of the symbol: macro / class / typedef / variable / function
    flags  modifiers;         // Bitfield used to mark some estra properties of symbol
                              // like that it is static or inline
    int    value_type_id;     // Id of symbol which represents c++ type of current symbol
                              // (like type of variable or type of returned value from function)
    int    extra_type_id;     // Extra type used in some cases
    list   children;          // List of child elements of this symbol (members in class etc)
    list   extra_lists[3];    // See table below
    map    extra_values;      // int -> string map which can keep some extra data
}
class list_entry
{
    int    symbol_id;         // ID of the symbol referenced
    int    storage_class;     // Storage class of the symbol (private/protected/public)
}

Explanation of symbol::extra_lists[]

type modifiers value_type_id extra_type children extra_lists[0] extra_lists[1] extra_lists[2]
namespace declarations in namespace "using" namespaces
class / struct / union members of class base classes template args friends of class
variable extern, static, volatile, const type of variable
function static, inline, const ... returned value arguments template arguments
typedef pointer, array, reference, pointer_to_member base type type of class in pointer_to_member
enum items in enum
enum item id of enum
macro macro parts
macro part arg_to_string, va_args number of arg or -1

Comments:

  • Such representation would require some extra "hidden" symbols - for example when some complex type is returned from function, extra symbol of typedef representing proper value would be required.
  • Also in case of templates, typeid's should be threated in special way - negative value could mean to use template argument instead of some real type. Base types (the POD ones) should have some predefined type ids.


Questions:

  • why are we storing filepos_end? Wouldn't it be much more useful to store declaration, definition info?

Code::Completion

  1. Generate a list of all valid symbols in the current scope
    1. Take global list from C::SymbolTable
    2. Add in local scope parsed on the fly
  2. Reduce that list to what is likely
  3. Show that list to the user in some fashion
  4. Insert the proper solution on user request

More complex cases of C::C usage

Here we can put some more complex examples of c++ code where C::C may fail. Symbols that may be hard to find should be marked in bold

1: Fetching type of operator call

#include <string>
using namespace std;

int main(int,char**)
{
    ( string("first") + "second" + "third" ) . c_str();
    return 0;
}

2: Template classes

template<typename T> class Template
{
public:
    T& GetInstance() { return m_Instance; }
private:
    T m_Instance;
};

class Parameter
{
public:
    void PrintfText() { printf("Text"); }
};

int main(int,char**)
{
    Template<Parameter> Object;
    Object.GetInstance().PrintfText();
}