[Bug c++/90881] -Wunused-value false positive in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881 --- Comment #9 from Federico Kircheis --- Hi, did you consider my last comment (Comment 6)? I find it unfortunate that gcc will not warn anymore about unused variables in some circumstances. Maybe my example was not a good one, but I guess that a warning in `decltype(0,0)` would be useful if one intended `decltype(0.0)`.
[Bug c++/90881] -Wunused-value false positive in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Marek Polacek --- Fixed. The behavior is now asi outlined in Comment 5.
[Bug c++/90881] -Wunused-value false positive in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Sat Jun 22 14:43:00 2019 New Revision: 272585 URL: https://gcc.gnu.org/viewcvs?rev=272585=gcc=rev Log: PR c++/90881 - bogus -Wunused-value in unevaluated context. * cvt.c (convert_to_void): Don't emit unused warnings in an unevaluated context. * g++.dg/cpp0x/Wunused-value1.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/Wunused-value1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/90881] -Wunused-value false positive in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881 --- Comment #6 from Federico Kircheis --- > With my patch, we wouldn't warn on this second testcase. But clang++ > doesn't warn, either. Yes, I just wanted to point out that giving warning in unevaluated contexts has some benefits too. I believe gcc is doing a better job than clang or msvc. I actually thought about this bug, and would like to rephrase it. It's not a false positive, it's an usability bug. It's not problematic that gcc gives a warning, the text is problematic/misleading. It says "left operand of comma operator has no effect", and as I showed this is wrong. It should say "left operand of comma operator is not used" or something in that direction, since the warning should be about unused variables (`-Wunused-value`), and it would be correct. As a programmer I can see more easily what gcc is trying to say, and I would be less tempted to remove the unused variable because gcc did not told me it was useless. Now you might think, that this does not help me as programmer at all, since I would like to write warning-free code, and I might be tempted to remove the unused variable also in this situation. Therefore, just add the hint (as actually documented), to cast the variable to void! Exactly as on would normally do for other unused variables. I did not think about it, because I payed too much attention at the error text, and not the cause of the warning. This sample does compile, works as expected, and does not generate any warning. #include template struct status : std::false_type{}; template struct status : std::true_type {}; struct s1{int member;}; struct s2{int _member;}; int main(){ static_assert(status::value, "has member"); static_assert(!status::value, "has no member"); } What do you think?
[Bug c++/90881] -Wunused-value false positive in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881 --- Comment #5 from Marek Polacek --- (In reply to Federico Kircheis from comment #4) > (In reply to Jonathan Wakely from comment #1) > > Confirmed. We shouldn't give that warning in unevaluated contexts (decltype, > > sizeof, etc.) because unevaluated operands have no effects at all, with or > > without the comma operator. > > The compiler flag is about unused variables, not statements without effects. > > I guess it would be nice for > > > int main(){ > decltype(short(), int()) a = 1; > return a; > } > > > to have a warning that the left operand is unused (as of today), since here > SFINAE does not kick in: > > -- > : In function 'int main()': > :2:21: warning: left operand of comma operator has no effect > [-Wunused-value] > 2 | decltype(short(), int()) a = 1; > | ^ > -- > > But maybe there are not enough use-cases to be worth to diagnostic it. With my patch, we wouldn't warn on this second testcase. But clang++ doesn't warn, either.
[Bug c++/90881] -Wunused-value false positive in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881 --- Comment #4 from Federico Kircheis --- (In reply to Jonathan Wakely from comment #1) > Confirmed. We shouldn't give that warning in unevaluated contexts (decltype, > sizeof, etc.) because unevaluated operands have no effects at all, with or > without the comma operator. The compiler flag is about unused variables, not statements without effects. I guess it would be nice for int main(){ decltype(short(), int()) a = 1; return a; } to have a warning that the left operand is unused (as of today), since here SFINAE does not kick in: -- : In function 'int main()': :2:21: warning: left operand of comma operator has no effect [-Wunused-value] 2 | decltype(short(), int()) a = 1; | ^ -- But maybe there are not enough use-cases to be worth to diagnostic it.
[Bug c++/90881] -Wunused-value false positive in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881 --- Comment #3 from Jonathan Wakely --- That was quick!
[Bug c++/90881] -Wunused-value false positive in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00810.html
[Bug c++/90881] -Wunused-value false positive in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-14 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed. We shouldn't give that warning in unevaluated contexts (decltype, sizeof, etc.) because unevaluated operands have no effects at all, with or without the comma operator.