Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 352974

Summary: Support sorting completion proposals for members of composite types by declaration order
Product: [Tools] CDT Reporter: Achim Winkler <achim.winkler>
Component: cdt-editorAssignee: Project Inbox <cdt-editor-inbox>
Status: NEW --- QA Contact: Jonah Graham <jonah>
Severity: normal    
Priority: P3 CC: cdtdoug, yevshif, zeratul976
Version: 8.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Achim Winkler CLA 2011-07-25 04:11:59 EDT
Build Identifier: 20110615-0604

It is not possible to disable the sort of the content assist. If i type something like:

structure.

a window is opened with the members of the structure. The problem is, that the members are always sorted and there is no way to disable the sort. Preferences->C/C++->Editor->Content Assist->Present Proposals in alphabetical order do not change anything.

Reproducible: Always

Steps to Reproduce:
1. Create a typedef of a structure.

typedef struct
{
  int test2_u32;
  int test1_u32;
} test_ts;

2. Create the structure:

test_ts test_s;

3. Type "test_s." without " to see that there is no way to see the original order of the structure members. test1_u32 is always the first entry.
Comment 1 Nathan Ridge CLA 2017-01-15 21:10:48 EST
There are two issues here:

 1) Content assist always sorts candidate completion proposals
    alphabetically as part of a de-duplication step. Then, if
    "Present proposals in alphabetical order" is unchecked, it
    re-sorts the proposals by relevance. If two proposals have
    the same relevance (as in your example), their relative
    order will be preserved from the previous sort, which was
    the alphabetical one.

    This would be straightforward to fix by rewriting the 
    de-duplication step to preserve the relative order of the
    candidate proposals, and then only sort alphabetically if
    "Present proposals in alphabetic order" is checked.

 2) The index does not preserve the declaration order of members
    of composite types.

    This means that, when the index is used to build the list
    of candidate proposals (which happens when the structure
    whose fields are the candidates is defined in a different
    file than the one in which completion is being invoked),
    the order of the candidate proposals already will not be
    the declaration order. So, even with the above change, the
    resulting order will not be the declaration order.

    This is harder to fix. Controlling the order in which
    bindings are stored in the index is difficult, so the most
    practical solution would be to have each member store a 
    "position number". We currently do this for C++ fields
    (where we use the position to match up fields with 
    initializer list clauses during constexpr computations)
    but not for C fields, nor for C++ methods.