trunk.git/gcc/cp/call.c:529:8: style:inconclusive: Technically the member function 'z_candidate::rewritten' can be const. [functionConst] trunk.git/gcc/cp/call.c:530:8: style:inconclusive: Technically the member function 'z_candidate::reversed' can be const. [functionConst] trunk.git/gcc/cp/call.c:9194:8: style:inconclusive: Technically the member function '::NonPublicField::operator()' can be const. [functionConst] trunk.git/gcc/cp/call.c:9211:8: style:inconclusive: Technically the member function '::NonTrivialField::operator()' can be const. [functionConst] There may be some small value in making sure that member functions that consist only of a return statement are marked const.
Assuming this is meant to be an enhancement request to add new option to suggest to make member functions const the same enhancement request has already been raised in pr80711, so resolving as a dupe. (I don't suppose you are just noting that the four instances of the message below would be solved by marking the functions const. There must be many more such opportunities in GCC, as well as countless others where const could be put to good use.) If this is about something else please feel free to reopen the report and explain in some detail what it's about. (A more descriptive Summary would be helpful.) *** This bug has been marked as a duplicate of bug 80711 ***
Created attachment 48485 [details] text file
(In reply to Martin Sebor from comment #1) > Assuming this is meant to be an enhancement request to add new option to > suggest to make member functions const the same enhancement request has > already been raised in pr80711, so resolving as a dupe. It is an enhancement request, but for one source code file only, not the implementation of the feature in gcc. > (I don't suppose you are just noting that the four instances of the message > below would be solved by marking the functions const. There must be many > more such opportunities in GCC, as well as countless others where const > could be put to good use.) Indeed, all I am doing is noting four places where const could be used. However, cppcheck did look at the general case of all of the source code of the gcc compiler and it found 237 places. I only mentioned four in this bug report, to keep things simple. List attached.
After noticing pr94995 (and subsequently also your clarification in comment #3) I see I was wrong in my assumption. While I'm a big fan of const correctness and agree that those functions (and probably many others) could be declared const, I see more overhead than value in reports suggesting these types of improvements to the code base. If you think they're worthwhile to make, just do it. You can submit a patch for review but you don't even need to ask for approval to commit it (see https://www.gnu.org/software/gcc/svnwrite.html#all). OTOH, where I see much more value is in adding features to detect these opportunities and adding them to -Wall (and for those, having reports in Bugzilla is also important).
(In reply to Martin Sebor from comment #4) > ... I see more overhead than value in reports suggesting > these types of improvements to the code base. Righto. I've provided the list of all known 237 places, so I won't report any more from the list. I've checked about 20 of them and they look valid to me, but there could be some false positives. > If you think they're worthwhile to make, just do it. > You can submit a patch for review but you > don't even need to ask for approval to commit it (see > https://www.gnu.org/software/gcc/svnwrite.html#all). Thanks but no. I prefer to encourage other developers to write into gcc repository than do it myself. > OTOH, where I see much more value is in adding features to detect these > opportunities and adding them to -Wall (and for those, having reports in > Bugzilla is also important). Agreed. I find the best first step to getting a new feature into gcc is to point out as many as possible places in the source code of gcc where that feature would help. Whether 237 cases is enough is now in the hands of a keen developer with enough time to implement the feature.