Community
Participate
Working Groups
// declaration auto foo::bar( std::lock_guard<std::mutex> &, bool isOptional=true ) -> void; // the code in some function in the same class foo { std::mutex someMutex; std::lock_guard<std::mutex> guardMe( someMutex ); bar( someMutex ); // 'invalid arguments' message is shown bar( someMutex, true ); // no message - the parser recognizes it correctly } It is obvious that the parser gets confused by the optional argument. When it is provided then no error message is shown.
Could you please give a complete code example?
/* * eclipse-532903.cpp * * Created on: Mar 26, 2018 * Author: developer */ #include <mutex> class foo { auto bar( std::lock_guard<std::mutex> &, bool ) -> void; auto doIt() -> void { std::mutex someMutex; std::lock_guard<std::mutex> guardMe( someMutex ); bar( guardMe ); // 'invalid arguments' message is shown bar( guardMe, true ); // no message - the parser recognizes it correctly } };
You don't have a default argument in this example. The compiler gives the same error that Eclipse does.
Created attachment 273302 [details] Screenshot from my project where the message is shown
I apologize for the incomplete example. This example compiles: gcc -c eclipse-532903.cpp -Wall -Werror -pedantic -O3 -std=c++17 /* * eclipse-532903.cpp * * Created on: Mar 26, 2018 * Author: developer */ #include <mutex> using LockScope = std::lock_guard<std::mutex>; class foo { private: auto bar( LockScope &, bool ) -> void; auto doIt() -> void; }; auto foo::bar( LockScope &, bool isOptional = true ) -> void { (void) isOptional; } auto foo::doIt() -> void { std::mutex someMutex; LockScope guardMe( someMutex ); bar( guardMe, true ); // no message - the parser recognizes it correctly bar( guardMe ); // 'invalid arguments' message is shown } But, here it the error is not shown. Apparently the error may show up when the project is bigger. I attached a screenshot from my project with real code where you can see the error message. See the green and yellow arrow.
Does the error go away (in your original code) if you move the default argument from the out-of-line method definition, to the in-class declaration?
YES, the error goes away. AND you gave me the kick and also according to this article https://stackoverflow.com/questions/2842928/default-value-of-function-parameter I moved it into the declaration part and removed the suppress directive: now it works fine for me. The declaration and definition of "sendThreadSafeCommandToServer" function is BEFORE the screenshot so Eclipse could have seen the default parameter.
Thanks for the info. I'm not terribly surprised that Eclipse's handling of a default argument added in a function definition is buggy. The expected behavior is that the added default argument is only visible in the translation unit where it was declared, but this is difficult for Eclipse to model because Eclipse stores information about the function in a central place, not on a per-translation unit basis. If you're able to put together an example that triggers the Eclipse error while also compiling (it may require multiple files), I can try to investigate and see if it's something we can fix. However, if the workaround of moving the default argument to the declaration is acceptable to you, then I would just suggest going with that.
It is totally acceptable to me - if I would have read the SO article earlier then I wouldn't run into this issue. I will try to prepare an example which compiles and where Eclipse complains. May be starting to minimize the existing code will work... Thank you!
The following three files seem to be enough to reproduce the issue: test.hpp: struct LockScope {}; struct foo { void bar(LockScope&, bool); void doIt(); }; test.cpp: #include "test.hpp" test2.cpp: #include "test.hpp" void foo::bar(LockScope&, bool isOptional = true ) {} void foo::doIt() { LockScope l; bar(l, true); bar(l); }
I can envision a partial fix for this along the following files: In PDOMFile.createPDOMName(), if the binding is a function, and the name is a declaration or definition, then go through the AST parameters in the AST function declarator, and if any of them has a default argument that's not already present in the corresponding PDOM parameter, then add that default argument to the PDOM parameter. If any such default arguments were added, also recompute the PDOM function binding's "required argument count". This would only be a partial fix because it doesn't account for a function having different default arguments (or different number of default arguments) in different translation units. Supporting that would require a more fundamental change to the index model, where we store information about each declaration of the function in the index (including any default parameters in that declaration), and track which declarations are visible from which files.
