On 12/16/2017 05:47 PM, Jean-Marc Lasgouttes wrote:
> Le 16 décembre 2017 15:25:44 GMT+01:00, Richard Heck <rgh...@lyx.org>
> a écrit :
>
>     On 12/16/2017 04:52 AM, Jean-Marc Lasgouttes wrote:
>>     Le 16 décembre 2017 06:59:12 GMT+01:00, Richard Heck
>>     <rgh...@lyx.org> a écrit :
>>
>>         commit 71005d6c1079637d7127defc372a5aa4d62092b0
>>         Author: Richard Heck <rgh...@lyx.org>
>>         Date:   Sat Dec 16 00:59:07 2017 -0500
>>
>>             Fix #10894 compiler warnings.
>>         ---
>>          src/insets/InsetCitation.cpp |    4 ++--
>>          1 files changed, 2 insertions(+), 2 deletions(-)
>>
>>         diff --git a/src/insets/InsetCitation.cpp 
>> b/src/insets/InsetCitation.cpp
>>         index 8377796..236dda2 100644
>>         --- a/src/insets/InsetCitation.cpp
>>         +++ b/src/insets/InsetCitation.cpp
>>         @@ -253,8 +253,8 @@ docstring InsetCitation::toolTip(BufferView 
>> const & bv, int, int) const
>>           docstring tip;
>>           tip += "<ol>";
>>           int count = 0;
>>         - for (docstring const & key : keys) {
>>         -  docstring const key_info = bi.getInfo(key, buffer(), ci);
>>         + for (docstring const & kit : keys) {
>>         +  docstring const key_info = bi.getInfo(kit, buffer(), ci);
>>            // limit to reasonable size.
>>            if (count > 9 && keys.size() > 11) {
>>             tip.push_back(0x2026);// HORIZONTAL ELLIPSIS
>>
>>
>>     I do not think that we should use 'it' in variable names in
>>     range-based for(). These are not iterators, but variables.
>
>     True.
>
>     rh
>
>
> I see you use
> for (bvar : backs)
> I'd use (and I used elsewhere) the plain
> for (back : backs)
>
> Or key/keys...

I think in both those specific cases, those variables were already used.
In fact, the original switch from "key" to "kit" was due to a warning
that "key" hid a previous declaration. (Someone changed that one
previously, maybe you.) Of course, I could have changed the other one
instead, but it has larger scope, so would be easier to get wrong.

I'm surprised we do not get a warning for this from gcc. I'm also
surprised how often this seems to happen in our code. It could lead to
some very weird bugs.

Richard

Reply via email to