Very poor Autocomplete; possibility of polyfill?

[artagnon]

Hi,

Autocomplete is basically not working. At first, I thought it was my include path; for LLVM, it's very simple: "${workspaceRoot}/include". It doesn't even complete "Basic" to "BasicBlock" (token seen a couple of lines below) here:

Something is seriously wrong, and this should work even without parsing any headers; it knows that BasicBlock is some kind of type (struct, class, union), and this is all the information it needs to know to fill out the template argument.

I know precise autocomplete is hard, but can I suggest a polyfill of any-word autocomplete (like Atom)? We need any-token autocomplete anyway, for things like macro invocations (think ASSERT_EQ in gtest).

I also tried it on my codebase at work, and it's useless again.

[sean-mcmanus]

This sounds like it could be a bug. Does it repro with 0.10.5 still? Could you give more repro details?

[artagnon]

@sean-mcmanus Running 1.12, and the problem is very much there. Reproduction steps: open a Scratch.cpp and type out the following into it slowly:

#include <string>
//        ^~~~~~ does it complete "string" or "vector"?
#include <vector>

int main()
{
    std::vector<bool> bools;
//       ^~~~~~~~~~~ does it complete vector or bool?
    std::vector<int> ints;
//       ^~~~~~ the second time "vector" is encountered, still no complete.
    bools.emplace_back(false);
//  ^~~~~~~~~~~~~~~~~~ does it complete "bools"? How about "emplace_back"?
    bools.size();
//        ^~~~ what happened to "size"?
}

Atom autocompletes every single one of those words.

[sean-mcmanus]

1. The lack of autocomplete in #include, for keywords like "bool", and for local variables like "bools" are known missing feature which we intend to add (no ETA yet).
2. std:: should autocomplete with all the std classes that have had header files parsed, along with all the methods after the "." such as emplace_back and size. If your limitSymbolsToIncludedHeaders setting is set to the default of "false", then the includePath headers are not parsed by default, until you add the #include and then save the file. If that still doesn't work, are you able to do Go To Definition on the #include file to locate it?

[artagnon]

When I try to look up the definition of "string" in `#include <string>`, I get: ``` Unable to open 'string': File not found (/usr/include/c++/4.2.1/debug/string) ``` When I try to look up the definition of the "string" in `std::string`, I get nothing.

…

On Mon, Apr 10, 2017 at 10:07 AM, Sean McManus ***@***.***> wrote: 1. The lack of autocomplete in #include, for keywords like "bool", and for local variables like "bools" are known missing feature which we intend to add (no ETA yet). 2. std:: should autocomplete with all the std classes that have had header files parsed, along with all the methods after the "." such as emplace_back and size. If your limitSymbolsToIncludedHeaders setting is set to the default of "false", then the includePath headers are not parsed by default, until you add the #include and then save the file. If that still doesn't work, are you able to do Go To Definition on the #include file to locate it? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#280 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACRalIJOLzt9Ajy1q5W9RuHWiY7pD9Nks5rujePgaJpZM4KVW-c> .

[sean-mcmanus]

You should delete your .browse.vc.db (default location is OS-dependent) or change the databaseFilename to something like ${workspaceRoot}/.browse.vc.db. It looks like initially it found /usr/include/c++/4.2.1/debug/string as the header, but it no longer exists. We intend to fix the issue where old/deleted files aren't being removed from the browse datagbase.

[bobbrow]

autocomplete for #include will be tracked by #802.
The second issue is fixed by using the new IntelliSense engine (add "C_Cpp.intelliSenseEngine": "Default" to your settings.json to try it out). We are also tracking an issue to fix up the browse database when files are deleted with #464.