Skip to content

Overloaded functions are completed to duplicates #39

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
elemakil opened this issue May 30, 2013 · 4 comments · May be fixed by #43
Open

Overloaded functions are completed to duplicates #39

elemakil opened this issue May 30, 2013 · 4 comments · May be fixed by #43

Comments

@elemakil
Copy link

Hey,

If I use ac-clang-async to complete member functions which have different signatures, the
function name gets inserted twice. I think its best to show you the problem using images:

First Step: Completion menu shows all member function and also that the function has three signatures.

Step 01

Second Step: I have hit ret and the function's base name is inserted, now I'm selecting the function signature. At this step the function's name is already inserted twice.

Step 02

Third Step: I accept the completion candidate (hitting ret) and the malformatted function was inserted.

Step 03

@toojays
Copy link
Contributor

toojays commented Jun 2, 2013

It would be useful to know which revision of emacs-clang-complete-async this occurred with, and which version of clang it is built against.

Can you reproduce it with a simpler example (e.g. std::vector::assign())?

toojays added a commit to toojays/emacs-clang-complete-async that referenced this issue Jun 9, 2013
When returning a completion for a method which is implemented in a base class,
the name of the class where the method was declared is included, so that instead
of:

COMPLETION: what : [#const char *#]what() const

we receive:

COMPLETION: what : [#const char *#]Implementation::what() const

The extra semi-colons after the class name caused this completion to match a
regexp which was added in hara/auto-complete-clang@493944 (and merged in
Golevka/emacs-clang-complete-async@3176ea) to support Objective C. In this case,
the argument list in the above example would be determined to be ":what() const"
rather than just "()". This commit fixes the issue by avoiding that regexp
unless we are in Objective C mode.

This is probably the same issue as reported in
Golevka#39.
@toojays
Copy link
Contributor

toojays commented Jun 9, 2013

I can reproduce something like this now. In my case, it's is not because the functions are overloaded, but that they are initially defined in a base class, then overridden. This causes clang to output extra information about where the function was declared. Then auto-complete-clang.el incorrectly parses this information, which leads to the incorrect expansion you see.

I initially ran into my case when trying to expand std::domain_error::what(). Here's a small self-contained example to reproduce the problem.

class Interface
{
    virtual const char *what () const throw () = 0;
};

class Implementation : public Interface
{
    const char *what () const throw () { return "What?"; }
};

class Derived : public Implementation
{
    const char *something_else (int x);
};

int main (void)
{
    Derived obj;

    obj.|
}

The | shows where to put the cursor to reproduce the issue. At this point, the completion options include what and something_else. something_else completes as expected, but selecting what expands it to what:what() const, which matches the behaviour reported in this issue.

Looking in the `clang-complete buffer, the returned results for the two methods of interest here:

COMPLETION: something_else : [#const char *#]something_else(<#int x#>)
COMPLETION: what : [#const char *#]Implementation::what() const
COMPLETION: what : [#const char *#]Interface::what() const

We can see that the results for what include the class where they were declared, while the result for something_else does not. This makes a difference in the elisp function ac-clang-action, because what is getting picked up by the first string-match condition, rather than the second. This leads to us incorrectly deciding that the argument list is :what() instead of ().

Looking through the history, this first condition was originally added in hara/auto-complete-clang@4939442 then merged into this project in 3176ea3b.

I've added a trivial workaround for this in toojays/emacs-clang-complete-async@229e5ba.

@elemakil, does this fix the problem you are seeing?

@elemakil
Copy link
Author

elemakil commented Jun 9, 2013

@toojays Indeed, this seems to fix it. Can we expect that this fix gets merged into @Golevka 's repository or should I use yours instead?

toojays added a commit to toojays/emacs-clang-complete-async that referenced this issue Jun 10, 2013
When returning a completion for a method which is implemented in a base class,
the name of the class where the method was declared is included, so that instead
of:

COMPLETION: what : [#const char *#]what() const

we receive:

COMPLETION: what : [#const char *#]Implementation::what() const

The extra semi-colons after the class name caused this completion to match a
regexp which was added in hara/auto-complete-clang@4939442 (and merged in
Golevka/emacs-clang-complete-async@3176ea3) to support Objective C. In this
case, the argument list in the above example would be determined to be ":what()
const" rather than just "()". This commit fixes the issue by avoiding that
regexp unless we are in Objective C mode.

This fixes Golevka#39.
@toojays
Copy link
Contributor

toojays commented Jun 10, 2013

Can we expect that this fix gets merged into @Golevka 's repository or should I use yours instead?

I've submitted a pull request for this fix as #43. I imagine a fix will eventually be merged in some form but that's up to @Golevka.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants