Community
Participate
Working Groups
In the following example "result.push_back(*it);" Is marked with "Invalid Argument" by Code analysis. #include <iostream> #include <vector> #include <boost/tokenizer.hpp> #include <string> using namespace std; using namespace boost; int main() { vector<string> result; string temp; tokenizer<> tokens(temp); for (tokenizer<>::const_iterator it = tokens.begin(); tokens.end() != it; ++it) { result.push_back(*it); } return (0); } I have already posted this, but I think It is in wrong place: https://bugs.eclipse.org/bugs/show_bug.cgi?id=348170
Is there problem with parsing headers? If you remove boost headers still reproduciable?
This is a Codan marker generated by the problem binding which is created by the Parser, I suggest changing component to cdt-parser. Btw- quite strange, as the type of the IASTExpression `*it` itself seems to be correctly deduced.
The root cause seems to be an error in parsing boost::iterator_traversal.
The following simple example reproduces the problem. #include <vector> #include <list> int main() { std::vector<int> vec_foo = { 1 }; std::vector<int> vec_bar; std::list<int> list_foo = { 1 }; std::list<int> list_bar; list_bar.push_back(list_foo.front()); vec_bar.push_back(list_foo.front()); list_bar.push_back(vec_foo[0]); vec_bar.push_back(vec_foo[0]); return 0; } On lines 11 & 12 (i.e. "list_bar.push_back(vec_foo[0]);" and "vec_bar.push_back(vec_foo[0]);") CDT reports: Invalid arguments 'Candidates are: void push_back(const int &) void push_back(int &&) '. However, "g++ -std=c++11" compiles cleanly. Note that CDT does *not* complain about lines 9 & 10. It seems that the return value of vec_foo[0] is not being parsed correctly. Note also that replacing with vec_foo.at(0) has no effect. I am using CDT 8.1 (Ubuntu 13.04 eclipse-cdt-8.1.0+dfsg-2).
I found that the problem goes away for the example above if c++11 support is disabled. That is, when I remove "-std=c++11" from the CDT GCC Builtin Compiler Settings in C/C++ General->Preprocessor Includes->Providers and rebuild the index, the error is no longer reported. Of course, this doesn't do much good if the project requires c++11 support.
Adam, do you still have this problem with CDT 8.2 (Kepler)? Both of the examples posted here work fine for me.
With CDT 8.3, Adam's sample is no longer exhibiting this error. However, the following sample does exhibit the error: #include <list> int main() { std::list< int > list_foo; std::list< int > list_bar; list_foo.splice( list_foo.end(), list_bar ); return 0; } As Adam previously described, the issue only appears when C++11 (C++0x on older versions of GCC) support is enabled, which leads me to believe Eclipse's parser is not correctly interpreting rvalue references, since the change of the second parameter from an lvalue reference (std::list& __x) to an rvalue reference (std::list&& x) is the only difference in this function when C++11 is enabled.
(In reply to Doug Glidden from comment #7) > With CDT 8.3, Adam's sample is no longer exhibiting this error. However, > the following sample does exhibit the error: > > #include <list> > > int main() > { > std::list< int > list_foo; > std::list< int > list_bar; > > list_foo.splice( list_foo.end(), list_bar ); > > return 0; > } > > As Adam previously described, the issue only appears when C++11 (C++0x on > older versions of GCC) support is enabled, which leads me to believe > Eclipse's parser is not correctly interpreting rvalue references, since the > change of the second parameter from an lvalue reference (std::list& __x) to > an rvalue reference (std::list&& x) is the only difference in this function > when C++11 is enabled. I do not get any errors for this example. Note that in my standard library's <list> header, there are two overloads of splice(), one which takes an lvalue reference as the second argument, and one which takes an rvalue reference, and the call in this example matches the lvalue reference one (as evidenced by 'Open Declaration' on 'splice' in the example taking me to that one). What compiler version are you using?
(In reply to Nathan Ridge from comment #8) > I do not get any errors for this example. Note that in my standard library's > <list> header, there are two overloads of splice(), one which takes an > lvalue reference as the second argument, and one which takes an rvalue > reference, and the call in this example matches the lvalue reference one (as > evidenced by 'Open Declaration' on 'splice' in the example taking me to that > one). > > What compiler version are you using? I am using GCC 4.4.7 (I know it's old, but it's the version included with RedHat/CentOS 6.4 Final, so I'm stuck with it). My <list> header also includes both of those definitions of splice(), but they are #ifdef-ed to ensure that only one or the other will exist; when C++0x support is enabled, only the rvalue version is defined; otherwise, only the lvalue version is defined. The final C++11 standard definitely indicates that both versions should be defined, but GCC 4.4.7 was based on a preliminary version of the standard that was, shall we say, incomplete. It's curious that GCC has no problem compiling the code, but after a little reading, I think Eclipse is probably technically correct, at least according to the final C++11 spec. In any case, explicitly casting the argument to an rvalue (i.e. (std::list< int >&&) list_bar) works around the problem.
(In reply to Doug Glidden from comment #9) > (In reply to Nathan Ridge from comment #8) > > I do not get any errors for this example. Note that in my standard library's > > <list> header, there are two overloads of splice(), one which takes an > > lvalue reference as the second argument, and one which takes an rvalue > > reference, and the call in this example matches the lvalue reference one (as > > evidenced by 'Open Declaration' on 'splice' in the example taking me to that > > one). > > > > What compiler version are you using? > > I am using GCC 4.4.7 (I know it's old, but it's the version included with > RedHat/CentOS 6.4 Final, so I'm stuck with it). My <list> header also > includes both of those definitions of splice(), but they are #ifdef-ed to > ensure that only one or the other will exist; when C++0x support is enabled, > only the rvalue version is defined; otherwise, only the lvalue version is > defined. The final C++11 standard definitely indicates that both versions > should be defined, but GCC 4.4.7 was based on a preliminary version of the > standard that was, shall we say, incomplete. It's curious that GCC has no > problem compiling the code, but after a little reading, I think Eclipse is > probably technically correct, at least according to the final C++11 spec. > In any case, explicitly casting the argument to an rvalue (i.e. (std::list< > int >&&) list_bar) works around the problem. GCC 4.4 was released in 2009, 2 years before the C++11 standard was finalized. At the time, an rvalue reference was allowed to bind to an lvalue; this was then changed to be disallowed in the final version of the standard. GCC labels its C++11 support as experimental, and makes it clear that they make no attempt to maintain backward compatibility with earlier versions that implement earlier drafts of a feature proposal [1]. Therefore I do not see much motivation in having Eclipse support such older C++11 feature variants, either. If someone does care to implement such an option in Eclipse, I imagine we would accept patches. [1] http://gcc.gnu.org/projects/cxx0x.html
(In reply to Nathan Ridge from comment #10) > GCC 4.4 was released in 2009, 2 years before the C++11 standard was > finalized. At the time, an rvalue reference was allowed to bind to an > lvalue; this was then changed to be disallowed in the final version of the > standard. > > GCC labels its C++11 support as experimental, and makes it clear that they > make no attempt to maintain backward compatibility with earlier versions > that implement earlier drafts of a feature proposal [1]. Therefore I do not > see much motivation in having Eclipse support such older C++11 feature > variants, either. If someone does care to implement such an option in > Eclipse, I imagine we would accept patches. It's now been 4 years since I wrote this, GCC 4.4 has been unsupported for several years, and the older variant of C++0x rvalue references that it implemented is becoming more and more irrelevant as time passes. I think it's safe to close this bug as WONTFIX.
