Community
Participate
Working Groups
I use El Capitan with XCode 7.2.1, eclipse cdt nightly build from yesterday. Similar to bug #488456 there are problems with std::vector: #include <vector> #include <string> int main() { std::vector<std::string> test(1); test[0].c_str(); // <----- error "c_str() could not be resolved" std::vector<std::string>::iterator x = test.begin(); x->does_not_exist(); // <---- no error at all return 0; } content assist does not work on "x->" and test[0] as well.
Works for me on Linux, with libc++ headers (the same ones that allowed me to reproduce bug 488456), with the latest nightly.
Could you upload a preprocessed file, as described in bug 488456 comment 1? Thanks!
Created attachment 260146 [details] preprocessed cpp file The preprocessed file works.
Hmm it looks like rebuilding the index helps here, so I guess it's not an indexer bug. I should have tried this first but it looked so similar to the problem with the map. But: It can be reproduced here any time by creating the default c++ "hello world" project, adding vector and string includes and putting std::vector <std::string, std::string> v; v[0].c_str(); at the start of main. Only an indexer rebuild will remove the problems. To which category should the bug be moved?
(In reply to Michael Teske from comment #4) > Hmm it looks like rebuilding the index helps here Ah, that explains why I couldn't reproduce it. > It can be reproduced here any time by creating the default c++ "hello world" > project, adding vector and string includes and putting > std::vector <std::string, std::string> v; > v[0].c_str(); > at the start of main. > Only an indexer rebuild will remove the problems. I still can't reproduce it like this, but that's probably because on my system, a newly created project uses libstdc++ headers by default, and I have to explicitly change it to use libc++, which triggers a re-index. I suspect that if the project used libc++ headers from the start, I could probably reproduce your problem. > To which category should the bug be moved? It's fine where it is. Errors that go away with a re-index are still indexer bugs, they're just hard to debug, and lower priority than errors that persist after a re-index.
fine. Let me know if I can do anything to help (e.g. trying test versions, provide some info, whatever). Anyway, you're right, priority is not that high anymore.
(In reply to Michael Teske from comment #6) > Let me know if I can do anything to help (e.g. trying test versions, > provide some info, whatever). The next step would be to reduce the problematic code example across the libc++ headers, until it's self-contained, similar to bug 488456 comment 3. (The nature of this bug means that, unlike bug 488456 comment 3, the reduced example will still include at least one header file, but the contents of that header can be minimized.) This is tricky to do, and time-consuming because - as the problem goes away with a reindex - you'd basically have to create a new project at each step of the reduction. I'd say it's probably not worth your time.
