Opened 12 years ago
Closed 12 years ago
#4776 closed Patches (fixed)
Mods to search_n test to show msvc failure
Reported by: | Owned by: | Neil Groves | |
---|---|---|---|
Milestone: | Boost 1.46.0 | Component: | range |
Version: | Boost Development Trunk | Severity: | Problem |
Keywords: | Cc: |
Description
The range trunk test matrix shows a couple stray failures for msvc tests. As you probably suspect, the problem seems to be in msvc's std lib.
These mods to the test prove it. (See attached patch.)
Attachments (2)
Change History (10)
by , 12 years ago
Attachment: | test_range_search_n.patch added |
---|
comment:1 by , 12 years ago
comment:2 by , 12 years ago
A more complete patch & results...
Running 1 test case... unknown location(0): fatal error in "test_search_n": C:\Program Files\VS8\VC\INCLUDE\list(213) : Assertion failed: list iterator not dereferencable ..\libs\range\test\algorithm_test\search_n.cpp(34): last checkpoint: Pre-std: class std::list<int,class std::allocator<int> >; value: 9; n:2; size:9 *** 1 failure detected in test suite "Master Test Suite"
by , 12 years ago
Attachment: | test_range_search_n_v2.patch added |
---|
comment:3 by , 12 years ago
Also, can this mode of failure for relevant platforms be marked as an "expected" failure, allowing the entire range library to not be marked as fail/yellow on the main matrix?
comment:4 by , 12 years ago
Severity: | Optimization → Regression |
---|
comment:5 by , 12 years ago
Severity: | Regression → Problem |
---|---|
Status: | new → assigned |
I'm going to tackle this slightly differently. There isn't an "expected" failure of Boost.Range this is unfortunately an expected failure of the Visual C++ standard library as you have described. Hence it is misleading to make my Boost.Range test fail since the algorithm actually works. This test result should pass. I shall modify the test to check for the correct result rather than test for equivalence to the standard library implementation.
comment:6 by , 12 years ago
Excellent. A passing test is much more valuable than an explained failure.
I think it's very useful/helpful (and interesting) to see the standard library failure as my patch shows, and would love it to be kept around for the record, but if you can't find a place for it, I understand.
comment:7 by , 12 years ago
I have altered the implementation as proposed earlier. It no longer uses the standard library implementation in either the core implementation or in the test. I shall monitor the progress on the trunk regression tests before a subsequent merge to the release branch.
comment:8 by , 12 years ago
Milestone: | To Be Determined → Boost 1.46.0 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Here's what it generates...