autocomplete for unique_ptr not working

已完成

So with the following example:

```

std::unique_ptr<std::string> p(new std::string);

p-> (should show std::string functions, instead shows unique_ptr functions)

```

How do I get the `p->` to show the correct auto complete?  This also applies to navigating the code.  If I had `p->empty()` and wanted to move to `empty()` it wouldn't know what it was to navigate.

I feel like at one point this worked but doesn't any more, but I don't use code with unique_ptr enough to be sure until lately.

I have invalidated my cache multiple times.  I have nuked my cmake-build-* directories and tried reloading cmake/building clean, etc.  Nothing seems to make auto complete parse properly.

Any ideas?

 

Edit: no idea how to do code tags on this forum... Tried a few things, didn't work, lol.. sorry. :)

3

Hi, Mike.

Could you please specify which compiler and CLion version you are using?

0

I got the same problem as described in the post. 

CLion 2017.1.3
Build #CL-171.4694.31, built on June 8, 2017

gcc 7.1.1

Also my smart pointers are marked red when using members, like this:

currentScreen_->Update(elapsed.asSeconds());

When hovering currentScreen_ it says 

"Applying '->' operator to 'unique_ptr<GameScreen>' instead of a pointer."

My project compiles just fine. I also do think that the behaviour occured the first time after updating Clion the last time.

3

Yea I have the exact environment that Tobias has.

Gcc 7.1.1 and just updated to 2017.1.3, but I did that in an attempt to fix the issue, so it was present in 2017.1.2.

I recently upgraded to gcc 7 (a week or 2 ago) so that could be the issue.  I swear I remember this working before.

Edit: also have the same "red" behavior that he has on using the pointer too.  How did you do a code block btw? lol

1

@Mike you could be right with GCC causing this behaviour. 

Regarding the code block: I just copied from Clion and pasted xD

0

Yea I'm pretty sure that's the issue since the warning it shows me in Clion talks about the "new Whatever" passed into the unique_ptr is not of type "remove_reference<...>".  Which is not the right definition of the function when I navigate to it.

Hopefully Anna can help us find a workaround though since this project I'm on right now has a lot of unique_ptr and shared_ptr. :)

0

We are sincerely sorry for the inconvenience. We have the issue in the tracker already: https://youtrack.jetbrains.com/issue/CPP-9949. It's a bug in CLion related to the latest GCC version support. Please add your comment or upvote. Hope it will be fixed soon.

 
1

Thanks Anna!  I figured it was created by the new gcc since it seemed to work before and that is the only change I can think of recently.  I will upvote the bug although I'm sure they will work on it quickly as it will affect a lot of linux users. :)

0

I'm still having this issue on the latest version of CLion.

See the example code below:

#include <memory>
#include <iostream>

struct Foo {
int bar;
};

int main() {
// no autocomplete but compiles and works
// warning: Applying '->' operator to 'std::unique_ptr<Foo>' instead of a pointer
std::unique_ptr<Foo> foo(new Foo);
foo->bar = 123;
std::cout << foo->bar << std::endl;

// no autocomplete but compiles and works
// warning: Redundant get() call on smart pointer
foo.get()->bar = 456;
std::cout << foo.get()->bar << std::endl;

// no autocomplete but compiles and works
// warning: Applying '->' operator to 'std::unique_ptr<Foo>' instead of a pointer
auto foo2 = std::make_unique<Foo>();
foo2->bar = 789;
std::cout << foo2->bar << std::endl;

// autocomplete works and compiles, but ugly
foo2.operator*().bar = 987;
std::cout << foo2.operator*().bar << std::endl;

// autocomplete works, compiles, less ugly but not great
(*foo2).bar = 654;
std::cout << (*foo2).bar << std::endl;

return 0;
}
1

Hi !

I 'm experiencing the same problem with std::shared_ptr.

Could you check if this is a bug?

CLion 2018.1
Build #CL-181.4203.549, built on March 27, 2018
Licensed to ##### ####
You have a perpetual fallback license for this version
Subscription is active until April 27, 2019
JRE: 1.8.0_152-release-1136-b20 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.10.0-42-generic

Running on Ubuntu Xenial

% c++ --version
c++ (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609

0

@Hideo-t, please update CLion to 2018.1.2 and check whether the issue still persists.

0

Thanks Anna!

It worked as expected with 2018.1.2. Great!

I didn't notice that I was one release behind the latest release.

I switched to using JetBrains Toolbox so I won't miss future releases.

 

0

Hi everyone, I'm using the 2019.1.2 version and the autocompletion using shared_ptr doesn't work, I don't see any error but I just don't see what I can use.

Do I need to change anything with this version of CLion? thank you

0

@Emin Demiri, is your project CMake-based? Does it behave the same way in a default "Hello, World!" project (File | New Project > C++ Executable)?

0

@Anna Falevskaya my project is a djinni projet ans is based on CMake.

On VisualStudioCode the same project autocomplete all functions of any objects.

 

 

 

0

@Emin Demiri, does the issue happen in "Hello, World"?

0

@Anna Falevskaya when creating a new project, working correctly.

0

I don't know if it helps at all but I have a Djinni project that I'm working on... weird coincidence since I started this thread ages ago before I had even knew about djinni, lol.

Anyway, with the most recent clion I just tested my project and it finds the shared_ptr autocompletion just fine, just like VSCode does. My guess is you have a configuration issue somewhere in your cmake and it's not able to resolve the shared_ptr properly.

Here's a screenshot showing it working. Sorry I couldn't show more it's proprietary code that I wouldn't have rights to share but this one line example won't hurt anyone.

Corresponding djinni code:

Side note, as much as I love jetbrains and clion I've been using vscode for this djinni project because of the need to hop between c++, java, and objective-c all the time.  CLion can't handle that so I find I just naturally end up using vscode.  Using clion on a djinni project is just not as useful since it mixes those languages.

0

请先登录再写评论。