This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] [test] Fix MSVC warning C4244 "conversion from 'X' to 'Y', possible loss of data", part 3/7.
ClosedPublic

Authored by STL_MSFT on Dec 7 2016, 2:01 PM.

Details

Summary

[libcxx] [test] Fix MSVC warning C4244 "conversion from 'X' to 'Y', possible loss of data", part 3/7.

Add static_cast<short> when constructing pair<Whatever, short> from (Something, int).

Diff Detail

Event Timeline

STL_MSFT updated this revision to Diff 80654.Dec 7 2016, 2:01 PM
STL_MSFT retitled this revision from to [libcxx] [test] Fix MSVC warning C4244 "conversion from 'X' to 'Y', possible loss of data", part 3/7..
STL_MSFT updated this object.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.
EricWF edited edge metadata.Dec 7 2016, 11:04 PM

MSVC seriously emits a warning for void foo(short); foo(0); because the literal 0 is an int? If so you really should fix that in MSVC; That's a bogus warning. Does it emit a warning for short x = 3;?

MSVC seriously emits a warning for void foo(short); foo(0); because the literal 0 is an int?

Oh my goodness it does... Your compiler is bad and it should feel bad. It's not like you can write foo(0s).

I can't possibly defend C1XX's behavior in your foo() scenario - but the pair scenarios being fixed here are different. pair<A, B>'s constructor from (X&&, Y&&) is perfect forwarding, so while the compiler can see that literals are being passed to (int&&, int&&), when it instantiates the constructor's definition, it just sees short being constructed from a perfectly-forwarded int, and warns about truncation there. C1XX doesn't attempt to "see through" the function call and notice that the arguments were literals. Its behavior is arguably desirable because the instantiation happens once per TU, and yet there may be other calls that are passing runtime-valued ints.

I chose static_cast<short> here because it was non-invasive, although ugly. There's a more invasive but prettier possibility - change the shorts to longs so that widening instead of truncation happens. I could do that if you want.

I checked, and Clang 3.8.0 behaves identically to C1XX in the pair scenario. Here's the test case:

#include <utility>

template <typename A, typename B> struct Pair {
    A a;
    B b;
    
    template <typename X, typename Y> Pair(X&& x, Y&& y) : a(std::forward<X>(x)), b(std::forward<Y>(y)) { }
};

int main() {
    Pair<short, short> p(11, 22);
    return p.a == 11 && p.b == 22 ? 0 : 1;
}

With -Wconversion, this emits:

prog.cc:7:62: warning: implicit conversion loses integer precision: 'int' to 'short' [-Wconversion]
    template <typename X, typename Y> Pair(X&& x, Y&& y) : a(std::forward<X>(x)), b(std::forward<Y>(y)) { }
                                                            ~^~~~~~~~~~~~~~~~~~
prog.cc:11:24: note: in instantiation of function template specialization 'Pair<short, short>::Pair<int, int>' requested here
    Pair<short, short> p(11, 22);
                       ^
prog.cc:7:85: warning: implicit conversion loses integer precision: 'int' to 'short' [-Wconversion]
    template <typename X, typename Y> Pair(X&& x, Y&& y) : a(std::forward<X>(x)), b(std::forward<Y>(y)) { }
                                                                                   ~^~~~~~~~~~~~~~~~~~

So, if you were compiling your tests with -Wconversion and not suppressing warnings in "system headers", you'd see this in libc++ too.

EricWF accepted this revision.Dec 8 2016, 12:22 PM
EricWF edited edge metadata.

Huh. Thanks for the analysis. LGTM.

This revision is now accepted and ready to land.Dec 8 2016, 12:22 PM
STL_MSFT closed this revision.Dec 8 2016, 1:57 PM