Arrow operator exposes methods available by value

[Yanpas]

There is smart dot operator handling in ccls which lets you call methods of smart pointer targets. But if you use arrow operator you see smart pointer methods in the first place for some reason.

struct A {
    void m1();
};

struct B : private A {
    void m2();
};

void foo () {
    std::unique_ptr<A> ap;
    ap->

[MaskRay]

Duplicate of #99

An initialization option to disable it may be useful.

[Riatre]

This is actually a valid bug caused by ac2d921, ccls should put smart pointer methods after methods of the wrapped object, and it did try to do so. However VSCode sorts the completion result according to (score, sortText) again, where score is a fuzzy matching score between filterText and user input computed by VSCode.

For example, consider these two results for file->|:

[{
        "label": "ToFunc",
        "kind": 2,
        "detail": "ToFunc(Usr usr) -> IndexFunc &",
        "sortText": "   !",
        "filterText": "ToFunc",
        "insertTextFormat": 1,
        "textEdit": {
          "range": {
            "start": {
              "line": 472,
              "character": 8
            },
            "end": {
              "line": 472,
              "character": 8
            }
          },
          "newText": "->ToFunc("
        }
},
{
        "label": "get",
        "kind": 2,
        "detail": "get() const -> pointer",
        "sortText": "   9",
        "filterText": "->get",
        "insertTextFormat": 1,
        "textEdit": {
          "range": {
            "start": {
              "line": 472,
              "character": 6
            },
            "end": {
              "line": 472,
              "character": 8
            }
          },
          "newText": ".get()"
        }
}]

VSCode takes the text between .textEdit.range.start and .textEdit.range.end as "user input", for ToFunc it would be empty, for get it would be "->", we have to include this part in filterText, otherwise results overlapping with existing texts will be filtered out. This was done in the commit mentioned before. However, because LCP("ToFunc", "") = 0, LCP("->get", "->") = 2, the fuzzy matching score of get is larger than the score of ToFunc, so it will always be put at the top of the completion result, which is not expected.

[MaskRay]

Thank you for looking into the VSCode internals!

However VSCode sorts the completion result according to (score, sortText) again

Is score a VSCode internal?

#210 "Fix completion result sorting in VSCode"

The fix is based on the assumption that we have to prefix filterText with ->. Can we make assumptions on the order how VSCode applies textEdit and additionalTextEdits that is not regulated in the spec? I don't really like the idea but it may give us cleaner workaround.

[MaskRay]

We can also just disable textEdit (CCOpts.IncludeFixIts = false;) in textDocument/completion results as clang only supports -> <=> . for now and it does not seem very useful.

[Yanpas]

Agree

[Riatre]

Is score a VSCode internal?

Yes.

Can we make assumptions on the order how VSCode applies textEdit and additionalTextEdits that is not regulated in the spec?

VSCode applies textEdit first, then all additionalTextEdits sequentially. IIRC all the ranges returned by Clang is based on the state before any edits, so we still have to make some adjustments. I agree that may lead to a cleaner workaround, I'm going to try this.

[Riatre]

I was wrong. I have tried this and the same thing described in microsoft/language-server-protocol#543 happened. It looks like LSP explicitly mentioned that having textEdit and additionalTextEdits on the same line is unsupported, but VSCode do accept such responses and additionalTextEdits gets applied first. (Which is strange because I can see these edits pops earlier in undo stack ?!)

So we can either:

1. Swap textEdit and additionalTextEdits.
2. Change the range of textEdit according to the assumption that additionalTextEdits gets applied first.

I'm sure 1 is going to break other clients, and I'm not sure whether 2 is cleaner than #210 since if you change range, you have to also change filterText accordingly for the same reason.

[MaskRay]

I agree that additionalTextEdits may be applied before textEdit.. #210 doesn't look too bad then as other clients may apply textEdit before additionalTextEdits..

https://github.com/Microsoft/vscode/blob/master/src/vs/editor/contrib/suggest/suggestController.ts#L235