GNOME Bugzilla – Bug 639955
[PATCH] Fix ReadOnlyCollectionTests.test_immutable_iterator
Last modified: 2011-01-20 11:02:15 UTC
Created attachment 178732 [details] [review] Proposed patch In Ubuntu, we were noticing that libgee started failing rebuild tests recently (we're not sure when it first started). This is without an update on libgee's part. Rather something changed in one of its dependencies. The problem was that ReadOnlyCollectionTests.test_immutable_iterator was failing with: ERROR:testreadonlycollection.c:293:read_only_collection_tests_test_immutable_iterator: assertion failed: (g_strcmp0 (_tmp9_, "one") == 0) Looking into it, it seems that for HashMultiSet<string>, the order of the two elements was being iterated differently than the order they were added. Which seems to be a fine and proper thing for a HashMultiSet to do, but the test isn't expecting it. So I have a patch to make the test a little more forgiving of whatever the underlying implementation wants to do. But I haven't yet tracked down *why* it changed. Do you all have any ideas? glib's g_string_hash didn't change. I compiled with an older version of valac (0.11.2) so I don't believe vala changed anything on us.
(In reply to comment #0) > Created an attachment (id=178732) [details] [review] > Proposed patch > > In Ubuntu, we were noticing that libgee started failing rebuild tests recently > (we're not sure when it first started). This is without an update on libgee's > part. Rather something changed in one of its dependencies. > > The problem was that ReadOnlyCollectionTests.test_immutable_iterator was > failing with: > > ERROR:testreadonlycollection.c:293:read_only_collection_tests_test_immutable_iterator: > assertion failed: (g_strcmp0 (_tmp9_, "one") == 0) > > Looking into it, it seems that for HashMultiSet<string>, the order of the two > elements was being iterated differently than the order they were added. Which > seems to be a fine and proper thing for a HashMultiSet to do, but the test > isn't expecting it. > > So I have a patch to make the test a little more forgiving of whatever the > underlying implementation wants to do. > > But I haven't yet tracked down *why* it changed. Do you all have any ideas? > glib's g_string_hash didn't change. I compiled with an older version of valac > (0.11.2) so I don't believe vala changed anything on us. No. I have no idea but the code is wrong anyway. I've fixed this in master (https://bugzilla.gnome.org/show_bug.cgi?id=639955) but I believed it is vala change so I haven't backported it.
I'm sorry but I've decided to backport a patch to keep both branches in some sort of sync. commit b004e916eff71621ce4f635f8ef683253eb9721e Author: Maciej Piechotka <uzytkownik2@gmail.com> Date: Mon Dec 27 15:37:43 2010 +0100 Remove depending on order of iteration in read-only collections' test