[cfe-dev] Autocompleting functions based on first parameter

[Alex L via cfe-dev]

Hi Michael,

On 10 January 2017 at 16:00, Michael Kruse via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi everyone,
>
> I am interested in improving clang's autocompletion to also suggest
> free functions that can take the expression at the cursor as first
> parameter, in addition to the methods its class has. I am interested
> in opinions and suggestions on how to implement it.
>
> Currently, YouCompleteMe and clang-complete, after typing (| = cursor
> position)
>
> std::string str;
> str.|
>
> will suggest std::string's methods (std::string::size(),
> std::string::push_back(), etc.), but not free functions such as
> std::stoi, std::stod, std::hash, etc. These are operations on the
> string as well, but for various reason are not members of std::string.
> Adding them to the autocompletion would make them more discoverable.
>
> When selecting a free function, eg. stoi, completion would change the
> "str." line to
>
> std::stoi(str, |
>

I think this could be an interesting extension to the current code
completion engine.
Although I feel like sometimes it might lead to more annoying clutter that
users don't want,
so it would be a good idea to allow users to control it using some global
setting.


> Languages such as C# have extension methods that allow keeping the
> class definition smaller and have additional functionalities in
> separate compilation units while still being discoverable using
> autocompletion. Unfortunately there is nothing equivalent in C or C++.
>
> This could be even more useful for C-style char*. Typing "str" and
> then triggering autocompletion allows to browse a list of
> string-related functions, but neither it is complete (eg. atoi won't
> appear) nor contains only string-related functions (eg.
> std::streambuf). Typing the argument first and then get a list of
> operations might be more useful than having to know the operation
> first.
>

I'm not 100% convinced by the use of this feature for char * completions.
Would you suggest the free functions for char * after "." or "->" or
perhaps both?


>
> Implementation
>
> I think it is not possible to implement this in YouCompleteMe or
> clang-complete only, support by clang is needed as it needs to know
> the expression's and parameter's types and their conversions. After
> looking at clang's C API for autocompletion that is used by
> YouCompleteMe and clang-complete (clang_codeCompleteAt), I think
> placing something at locations other than the cursor position or
> replacing previous characters doesn't seem to be possible. That is,
> there are only values in CodeCompletionString::ChunkKind that add
> text, but nothing to remove, overwrite or change the cursor position.
>

I think that's right, so this change will require changes to the libclang
completion API.
That said I don't think that API clients will struggle to adapt to the
change, as for
example Xcode can already deal with removal of N characters prior to
completion point, so
it should be straightforward enough to adapt it to the libclang changes
provided the API
isn't changed drastically.


>
> Eg. Visual Studio can automatically replace "." and "->", depending on
> whether the expression under the cursor is a class or
> pointer-to-class. This seems to be impossible to implement with the
> current interface.
>
> There is also a concern that enumerating a lot of free functions could
> lead to a significant delay.
>

Right. However, the code completion engine can cache certain global
declarations, so we could try
and utilize that (but I'm not 100% sure if the cache can be used in this
case).


>
>
> Background
>
> We are discussing a C++ interface for the Integer Set Library [1]
> which would make its reference counting automatically handled by RAII
> in Polly [2]. One point of discussion was whether to make C functions
> members of its classes or free functions in the isl:: namespace.
> Essentially, the choice between
>
> intersect(set1, set2);
>
> and
>
> set1.intersect(set2);
>
> The latter introduces an asymmetry between the arguments and raises
> the question whether the method modifies the object and/or returns a
> new one. It also does not do implicit conversions of the "this"
> argument. On the plus side, it does not pollute the isl:: namespace,
> is more object-oriented and allows browsing the interface using
> code-completion. The last point would not be an issue anymore if code
> completion also suggested functions.
>
> Regards,
> Michael
>
>
> [1] http://isl.gforge.inria.fr/
> [2] https://docs.google.com/document/d/1h89T_
> wKRFSimY8bn9estBI4p0pJZkj7Zu5ptSE7nybI/edit#
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170110/cd0b0445/attachment.html>