This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] [test] Fix MSVC x64 warning C4267 "conversion from 'size_t' to 'int' [or 'unsigned int'], possible loss of data", part 4/4.
AbandonedPublic

Authored by STL_MSFT on Nov 30 2016, 10:05 AM.

Details

Summary

[libcxx] [test] Fix MSVC x64 warning C4267 "conversion from 'size_t' to 'int' [or 'unsigned int'], possible loss of data", part 4/4.

Change a few allocators' size_type/difference_type from unsigned/int to std::size_t/std::ptrdiff_t.

This avoids truncation warnings on x64 when unsigned/int are 32-bit but std::size_t/std::ptrdiff_t are 64-bit.

Diff Detail

Event Timeline

STL_MSFT updated this revision to Diff 79775.Nov 30 2016, 10:05 AM
STL_MSFT retitled this revision from to [libcxx] [test] Fix MSVC x64 warning C4267 "conversion from 'size_t' to 'int' [or 'unsigned int'], possible loss of data", part 4/4..
STL_MSFT updated this object.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.
EricWF accepted this revision.Dec 10 2016, 6:12 PM
EricWF edited edge metadata.

This change looks OK to me. As mentioned above I think the reason the test allocators used int/unsigned is so they could detect if the container actually propagated their typedefs.
However there are other ways to test this.

test/std/utilities/allocator.adaptor/types.pass.cpp
78

This part of the change loses test coverage. Specifically it no longer tests that scoped_allocator_adaptor propagates the OuterAlloc's typedefs.

I would scribble out a minimal custom allocator at the top of this file, and rewrite these static asserts using that.

This revision is now accepted and ready to land.Dec 10 2016, 6:12 PM
EricWF requested changes to this revision.Dec 10 2016, 11:40 PM
EricWF edited edge metadata.

Actually I've changed my mind on this patch. While attempting to clean up -Wconversion errors in libc++ I found many of them were caused by these custom allocators providing a custom 32 bit size type. Since users are free to do this AFAIK it seems like we should keep these tests for it.

@STL_MSFT Does that make sense?

This revision now requires changes to proceed.Dec 10 2016, 11:40 PM

Yeah, users are free to do this, which also triggers conversion warnings for us. I think I'll need to investigate actually fixing/suppressing them in our sources and abandoning this patch; leaving it open for now as a todo.

STL_MSFT abandoned this revision.Dec 14 2016, 2:13 PM

Abandoning; I have changes in our STL to fix the bulk of these warnings, plus a small number of test changes that I'm about to send out.