Port DevCom bugs to GitHub

[StephanTLavavej]

As part of our work to migrate all STL development to GitHub, we're porting our Microsoft-internal bug database ("VSO"; originally Visual Studio Online, renamed Azure DevOps and Azure Boards) to GitHub issues. Some bugs were directly filed in VSO (by STL maintainers and other people within MS, sometimes on behalf of customers), while some were replicated from Developer Community ("DevCom").

As part of this porting process, we aren't resolving any bugs. The intended goal is for GitHub to be the source of truth for all bug reports (in addition to performance/enhancement/etc. suggestions); it's also our preferred place for new issues to be filed. (Issues filed on GitHub aren't replicated anywhere else, so it's the most convenient for us.) However, users who filed DevCom bugs in the past (or continue to file them in the future) will have their bugs remain active, and will receive feedback from STL maintainers there (in addition to their bugs being ported to GitHub issues where they can be linked to pull requests etc.). Additionally, VSO bugs (whether filed directly or replicated from DevCom) will remain active because our bosses and boss-like entities prefer that.

"Porting" a bug to GitHub involves capturing the true essence of the bug report, without distorting or over-simplifying it. (Much like compiler bugs, STL bugs can be very sensitive to the exact code, compiler options, etc. used.) However, we also want our GitHub issues to be readable and comprehensible, so that both maintainers and contributors can understand what's wrong and easily investigate a fix. So, when possible, it's nice to clean up the title and test case, so that they're as clear and minimal as possible. (It is often a good idea to have an "original repro" and "reduced repro", to avoid the dangers of over-simplifying away something important - and I speak as someone who has over-simplified a dozen compiler bug reports in the past.) It's better to err on the side of less cleanup than more - fixing only grammatical issues is fine.

Example bugs ported from DevCom: GH-371 (from DevCom-758960) and GH-503 (from DevCom-371962)

While only the STL maintainers will be able to port the MS-internal bugs that were directly filed in VSO, the DevCom database is publicly viewable, so we could use some help with those bugs. 😸

Here's a list of the DevCom bugs, along with their VSO IDs and Titles. (Sometimes, multiple DevCom bugs were linked to a single VSO bug, when we had a strong belief that they're all duplicates.) I generated this by hand, so if anything looks wrong (e.g. mismatched VSO/DevCom bugs), please let me know. Note that everyone in this repo has the ability to use our Custom Autolinks in GitHub issues/comments; you can just say DevCom-NNN instead of copying a whole URL.

In general, we have already tried to resolve clearly-invalid bugs, and obvious duplicates, but there are several categories of possible duplicates that we haven't resolved because there may be multiple underlying issues.

Finally, in addition to the title and repro, ported bugs should mention the DevCom and VSO IDs, so we can easily navigate to the linked bugs:

Also tracked by DevCom-publicnumber and VSO-internalnumber / AB#internalnumber.

AB followed by # (not - like other autolinks) will activate automation: your issue will be automatically edited by @msalehmsft to add a hyperlink (it won't appear in a Preview), and the internal bug will gain a special link. This must be mentioned in the original issue to create the internal link; using this syntax in issue comments below will be hyperlinked from GitHub, but not to GitHub.

Please don't use AB#nnn syntax here, in this thread as it will link "Port DevCom bugs to GitHub" to whatever's mentioned. DevCom-nnn and VSO-nnn are safe to mention anywhere.

🪲 Remaining: VSO ID | DevCom ID(s) | Original VSO Title

• All done!

⏳ In Progress

• None.

⚠️ Blocked

• Let us know if anything simply can't be ported due to test cases in non-public attachments, descriptions that don't make sense, etc. We'll handle these bugs separately.
• Non-public attachments:
  • VSO-238123 | DevCom-189336 | <iomanip>: std::get_time cause Debug Assertion Failed when the second parameter have extra delimiter
  • VSO-275595 | DevCom-246257 | <regex>: Instantiating std::regex("meow") changes output of strftime in a different thread
  • VSO-406125 | DevCom-246250 | <iomanip>: std::get_time does not report fail on an invalid date
• Non-public screenshots:
  • VSO-659137 | DevCom-305560 | <xlocale> et al. locale allocates memory while holding the locale lock
• Needs extra attention, see linked comments below:
  • Port DevCom bugs to GitHub #939 (comment) | VSO-399948 | DevCom-249123 DevCom-86665 DevCom-267556 | <regex> std::regex_search causes infinite recursion on a sample that works with Visual Studio 2013 and gcc

❌ Resolved As Invalid

• VSO-471859 | DevCom-87221 DevCom-246246 | <scoped_allocator>: std::scoped_allocator_adaptor copy constructor does not copy construct inner allocators
• <iostream> : When a double-width characters in cout, blank output without permission. #1122 | VSO-441122 | DevCom-59694 | <iostream> : When a double-width characters in cout, blank output without permission.

🛠️ Compiler Bug, Reduced To Library-Free Test Case And Sent To Compiler Team

• VSO-1168175 | DevCom-1139739 | std::thread ends up calling lambda from other file with new lambda engine
• <functional>: Passing an object with an explicit alignment that owns a std::function by value leads to invalid free on x86 #964 | VSO-720596 | DevCom-367683 | <functional>: Passing an object with an explicit alignment that owns a std::function by value leads to invalid free on x86

😸 Fixed

• VSO-454466 | DevCom-246251 | <scoped_allocator>: std::scoped_allocator_adaptor does not properly construct inner allocator
• <complex>: std::arg does not work for negative real values #785 | VSO-507908 | DevCom-125537 | <complex>: Passing a double to std::arg returns wrong result.
• <valarray>: slice_array's copy ctor is missing, the same with mask_array, gslice_array, indirect_array #940 | VSO-109266 VSO-366115 VSO-1141492 | DevCom-1075574 DevCom-246260 DevCom-1075573 | <valarray>: slice_array's copy ctor is missing, the same with mask_array, gslice_array, indirect_array
• <random>: piecewise_linear_distribution is still broken #950 | VSO-115939 | DevCom-421634 | <random>: piecewise_linear_distribution is still broken
• <filesystem>: Use of std::filesystem::path causes link error on UWP(already fixed) #1069 | VSO-718901 | DevCom-369081 | <filesystem>: Use of std::filesystem::path causes link error on UWP
• <deque>: Use _Next_iter and _Prev_iter #1161 | VSO-1166791 | DevCom-1134328 | MSVC fails to compile (C2666) simple std::stack<Class *> for x64 while for x86 it works fine

✔️ Done

• STL: Finish supporting /Wall #186 | VSO-1151642 | DevCom-1080802 | STL: Finish supporting /Wall
• <streambuf>: basic_streambuf doesn't support 64-bit properly #388 | VSO-485517 | DevCom-320893 DevCom-102668 DevCom-290124 DevCom-859581 | <streambuf>: basic_streambuf doesn't support 64-bit properly
• <locale>: Eagerly-allocated facets in non-default std::locale can lead to ODR violation between DLL-exported version and header version #412 | VSO-678119 | DevCom-329394 | <locale>: Eagerly-allocated facets in non-default std::locale can lead to ODR violation between DLL-exported version and header version
• <array>: std::array<T,0> doesn't compile - when type is not default constructible #942 | VSO-207715 | DevCom-813352 DevCom-238607 DevCom-329888 | <array>: std::array<T,0> doesn't compile - when type is not default constructible
• <iterator>: checked_array_iterator/unchecked_array_iterator should have conversions #943 | VSO-146139 | DevCom-241515 | <iterator>: checked_array_iterator/unchecked_array_iterator should have conversions
• <iomanip>: get_time should parse format without delimiters #944 | VSO-370548 VSO-257790 | DevCom-246365 DevCom-140618 DevCom-9505 | <iomanip>: get_time should parse format without delimiters
• <mutex>: change mutex to be an SRWLOCK #946 | VSO-685103 | DevCom-334696 | <mutex>: change mutex to be an SRWLOCK
• <exception>: std::exception::what has wrong signature #948 | VSO-1006425 | DevCom-785027 | <exception>: std::exception::what has wrong signature
• <future>: std::async with std::launch::async policy does not behave as if in new thread in regards to thread_local #949 | VSO-620282 | DevCom-256895 | <future>: std::async with std::launch::async policy does not behave as if in new thread in regards to thread_local
• <functional>: std::is_convertible is broken for std::bind functors #952 | VSO-671111 | DevCom-317991 | <functional>: std::is_convertible is broken for std::bind functors
• <valarray>: VS doesn't trigger the assertion when the data out of bound in std::valarray #953 | VSO-715060 | DevCom-364060 | <valarray>: VS doesn't trigger the assertion when the data out of bound in std::valarray
• <execution>: Including with /clr enabled results in compiler error. #955 | VSO-947547 | DevCom-642475 | <execution>: Including with /clr enabled results in compiler error.
• <memory>: _msize & std::allocator don't work together #966 | VSO-729275 | DevCom-380760 | <memory>: _msize & std::allocator don't work together
• <any>: std::any doesn't link when exceptions are disabled #990 | VSO-725649 | DevCom-376072 | <any>: std::any doesn't link when exceptions are disabled
• <regex> mishandles locale-based character classes outside of the char range #992 | VSO-273702 | DevCom-984204 | <regex> mishandles locale-based character classes outside of the char range
• <regex>: c++ regex character class case insensitive search problem #993 | VSO-287844 | DevCom-230267 DevCom-246258 | <regex>: c++ regex character class case insensitive search problem
• <regex>: Regex erroneously returns a match #994 | VSO-660624 | DevCom-306176 | <regex>: Regex erroneously returns a match
• <regex>: basic_regex wants regex_traits to provide things not required by [re.req] #995 | VSO-673897 | DevCom-322328 | <regex>: basic_regex wants regex_traits to provide things not required by [re.req]
• <regex>: regex_search behaves incorrectly when the regex contains R"(\[)" #996 | VSO-678814 | DevCom-326044 | <regex>: regex_search behaves incorrectly when the regex contains R"(\[)"
• <regex>: Grouping within repetition causes regex stack error #997 | VSO-1054746 | DevCom-885115 | <regex>: Grouping within repetition causes regex stack error
• <random>: Floating-point random number generation suboptimal due to generate_canonical() #1000 | VSO-976509 | DevCom-717452 | <random>: Floating-point random number generation suboptimal due to generate_canonical()
• <random>: binomial_distribution is broken #1001 | VSO-923008 | DevCom-606865 | <random>: binomial_distribution is broken
• <random>: Still provides the uniform_int and uniform_real class templates #1002 | VSO-729899 | DevCom-381099 | <random>: The <random> header still provides the uniform_int and uniform_real class templates
• <random>: normal_distribution is slower than Boost #1003 | VSO-486661 | DevCom-86909 | <random>: std::normal_distribution four times slower than the corresponding boost version
• <regex>: Error C2664 in std::regex_traits::transform #1004 | VSO-1142061 | DevCom-1076807 | <regex>: Error C2664 in std::regex_traits::transform
• <algorithm>: debug checks for predicates are observable #1006 | VSO-592348 | DevCom-222276 | <algorithm>: std::min_element() assumes the elements in the range are not modified
• <deque>: std::deque::insert performance #1023 | VSO-586319 | DevCom-216960 | <deque>: std::deque::insert performance
• <locale>: Empty locale name and UTF-8 issues #1033 | VSO-679264 | DevCom-330322 | <locale>: Empty locale name and UTF-8 issues
• <forward_list>, <string>, <vector>: Debug mode STL causes terminate() to be called under low memory #1035 | VSO-466800 VSO-470756 | DevCom-77779 DevCom-246249 | <string>, <vector> Debug version of STL is not exception safe and causes terminate() to be called under low memory
• <deque> : A deque<T> where T is move-only, when nested in vector, does not compile #1036 | VSO-399383 VSO-851210 | DevCom-33006 DevCom-536767 | <deque> : A deque<T> where T is move-only, when nested in vector, does not compile
• <xtree>: _Tree move constructor incorrectly swaps #1037 | VSO-951679 | DevCom-657074 | <xtree>: _Tree move constructor incorrectly swaps
• <chrono>: No diagnostic for truncating conversion of chrono duration #1040 | VSO-961527 | DevCom-671799 | <chrono>: No diagnostic for truncating conversion of chrono duration
• <vector>: VS 2019 ignores explicit keyword #1041 | VSO-636498 | DevCom-275079 | <vector>: VS 2019 ignores explicit keyword
• <xlocinfo>: Mismatched call to free when malloc is replaced with user implementation #1066 | VSO-470455 | DevCom-246248 | <xlocinfo>: Mismatched call to free when malloc is replaced with user implementation
• <locale>: Cannot run in Release mode and throw unhandled exception: std::runtime_error - UTF8 to GBK  #1068 | VSO-811511 | DevCom-471144 | <locale>: Cannot run in Release mode and throw unhandled exception: std::runtime_error - UTF8 to GBK
• C++/CLI & Inconsistent layout information in duplicated types (std._Tree_unchecked_const_iterator) #1070 | VSO-643625 | DevCom-279568 | C++/CLI & Inconsistent layout information in duplicated types (std._Tree_unchecked_const_iterator)
• <iomanip>: std::get_time asserts with "istreambuf_iterator is not dereferenceable" when format is longer than the stream #1071 | VSO-368195 VSO-713785 | DevCom-246363 DevCom-18311 DevCom-362423 | <iomanip>: std::get_time asserts with "istreambuf_iterator is not dereferenceable" when format is longer than the stream
• <random>: uniform_real_distribution(a, b) produces outputs outside [a, b) #1074 | VSO-253526 | DevCom-110322 | <random>: uniform_real_distribution<float> generates numbers outside of the interval
• <locale>: std::ctype<char>::blank return true for all space-characters #1121 | VSO-429255 | DevCom-215436 DevCom-246252 DevCom-51443 | <locale>: std::ctype<char>::blank return true for all space-characters
• <iostream>: hexfloat stream output does not ignore precision as it should #1125 | VSO-847068 | DevCom-520472 | <iostream>: hexfloat stream output does not ignore precision as it should
• <iomanip>: Case sensitivity when parsing months #1126 | VSO-596742 | DevCom-229445 | <iomanip>: Case sensitivity when parsing months
• <fstream>: ifstream putback is still broken #1171 | VSO-275515 VSO-425342 | DevCom-858136 DevCom-246367 | <fstream>: ifstream putback is still broken
• <locale>: locale initialization incorrect in debug mode #1175 | VSO-620209 VSO-622201 | DevCom-256346 DevCom-260195 | <locale>: locale initialization incorrect in debug mode

[StephanTLavavej]

@Amaroker, here's the list as you requested in #890 (comment). 😺

[AlexGuteniev]

Taking the first four:

• VSO-109266 | DevCom-1075574 | <valarray>: slice_array's copy ctor is missing | <valarray>: slice_array's copy ctor is missing, the same with mask_array, gslice_array, indirect_array #940
• VSO-146139 | DevCom-241515 | <iterator>: checked_array_iterator/unchecked_array_iterator should have conversions | <iterator>: checked_array_iterator/unchecked_array_iterator should have conversions #943
• VSO-207715 | DevCom-813352 DevCom-238607 DevCom-329888 | <array>: std::array<T,0> doesn't compile - when type has private ctor

Returning back, was not able to port:

• VSO-115939 | DevCom-421634 | <random>: piecewise_linear_distribution is still broken.

[AlexGuteniev]

So far the results about first four. Two successes:

• <valarray>: slice_array's copy ctor is missing, the same with mask_array, gslice_array, indirect_array #940
• <array>: std::array<T,0> doesn't compile - when type is not default constructible #942

Two failures:

• <iterator>: checked_array_iterator/unchecked_array_iterator should have conversions #943 - I tried to create after DevCom-241515 description, but it looks suspicious
• VSO-115939 | DevCom-421634 - It refers to old bug that was already fixed, by itself it describes something that I was not able to assess, Need a look from someone who understands math and floating points very well.

Is it good enough?

[Amaroker]

Thanks for the list. I filed a bug report for DevCom-246365 as #944

There are related issues in the list, for example DevCom-246250 and DevCom-189336.
The problem is that they refer to attached code. That code it not publicly available, which makes it difficult.

[Amaroker]

DevCom-334696 has been ported as #946

[AlexGuteniev]

• VSO-1006425 | DevCom-785027 | <exception>: VC++: std::exception::what has wrong signature | <exception>: std::exception::what has wrong signature #948

@StephanTLavavej , I'd suggest that you add checkboxes to your message, so that we copy lines in comment, and you mark checkboxes in your message after an initial check.

[AlexGuteniev]

• VSO-620282 | DevCom-256895 | It seems TLS is not initialized correctly in this case | <future>: std::async with std::launch::async policy does not behave as if in new thread in regards to thread_local #949

[statementreply]

• <random>: piecewise_linear_distribution is still broken #950 | VSO-115939 | DevCom-421634 | <random>: piecewise_linear_distribution is still broken

Edit: ported as #950, @StephanTLavavej

[StephanTLavavej]

Thanks @AlexGuteniev, @Amaroker, and @statementreply! I really appreciate it! 😺😸 I've updated the table to a checkbox list as requested, and created Remaining/In Progress/Done sections.

If anything simply can't be ported due to non-public attachments (or descriptions that don't make sense, etc.), let us know and we'll handle them separately. I've created a Blocked section for the ones you mentioned, @Amaroker.

[AlexGuteniev]

Ported these:

• <functional>: std::is_convertible is broken for std::bind functors #952 | VSO-671111 | DevCom-317991 | <functional>: std::is_convertible is broken for std::bind functors
• <valarray>: VS doesn't trigger the assertion when the data out of bound in std::valarray #953 | VSO-715060 | DevCom-364060 | <valarray>: VS doesn't trigger the assertion when the data out of bound in std::valarray
• <execution>: Including with /clr enabled results in compiler error. #955 | VSO-947547 | DevCom-642475 | <execution>: Including with /clr enabled results in compiler error.

Did not port:

• VSO-720596 | DevCom-367683 | <functional>: Passing an object with an explicit alignment that owns a std::function by value leads to invalid free on x86 (Note: Appears different than <functional>: std::function doesn't handle over-aligned types #690)
  • Indeed different from <functional>: std::function doesn't handle over-aligned types #690. Appears to be fixed before <functional>: std::function doesn't handle over-aligned types #690. Cannot recreate on VS 2019. Someone who have 2017 as well, please take a look.

[StephanTLavavej]

Thanks @AlexGuteniev, I've updated the list again, and @CaseyCarter has linked the MS-internal bugs.

I'm still able to reproduce the DevCom-367683 std::function alignment crash with VS 2019 16.7 Preview 3.1 (note that it is indeed x86 specific and doesn't repro for x64). I'll go ahead and port it.