Bug 57211 - wrong line indicated in warning for synthesized method
Summary: wrong line indicated in warning for synthesized method
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.8.0
: P3 normal
Target Milestone: 4.9.0
Assignee: Paolo Carlini
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2013-05-08 13:08 UTC by Matthias Klose
Modified: 2013-05-22 09:34 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.6.4, 4.7.3, 4.8.0
Last reconfirmed: 2013-05-22 00:00:00


Attachments
demonstration code showing problem and workaround (325 bytes, text/plain)
2013-05-15 05:37 UTC, Anthony Foiani
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Klose 2013-05-08 13:08:12 UTC
seen at least in 4.6, 4.7, 4.8 and trunk:

$ g++-4.8 -c -std=c++11 -Wunused-parameter  test.cpp
test.cpp:3:8: warning: unused parameter 'p' [-Wunused-parameter]
 struct A  // line pointed-to by warning
        ^
test.cpp: In function 'int main()':
test.cpp:21:11: note: synthesized method 'A& A::operator=(A&&)' first required here 
         b = std::move(a);
           ^

$ cat test.cpp 
#include <functional>

struct A  // line pointed-to by warning
{
        struct B
        {
                B& operator=(B&&) { return *this; }
        };

        B f;

        A() = default;
        A& operator=(A&& p) = default;  // where the method is declared
};

int main()
{
        A a;
        A b;

        b = std::move(a);
}
Comment 1 Anthony Foiani 2013-05-15 05:37:52 UTC
Created attachment 30117 [details]
demonstration code showing problem and workaround
Comment 2 Anthony Foiani 2013-05-15 05:40:20 UTC
I'm also seeing this bug, in version 4.7.2.

Instead of trying to fix the line offset, I believe the right thing is to not emit this warning in this case at all.

The parameter is certainly used, even if the synthesized method uses a different formal argument name.  (In which case, shouldn't it offer a corresponding undeclared variable error?)

Put another way: if the method has a signature which can be defaulted, then the parameter name(s) should be ignored.  (IMHO of course.)

A workaround is to omit the parameter name, but I feel that reduces readability.  (It also makes some documentation-generating tools sad, e.g., doxygen.)

See attached for a version of Matthias's code that shows workaround via macro flag.
Comment 3 Paolo Carlini 2013-05-22 09:34:26 UTC
Fixed for 4.9.0.