Fix MemoryPreferences::GetMultipleValue

[cho-m]

There is no guarantee on ordering of std::multimap::find https://en.cppreference.com/cpp/container/multimap/find:

If there are several elements with the requested key in the container,
any of them may be returned.

In recent LLVM / Apple Clang, the PreferencesTest fails as LLVM changed their implementation so the assumption of exact returned element is no longer true:

• [libc++] std::multimap .find() changed order in LLVM 22 llvm/llvm-project#193311

Instead, switch to an interface that provides ordering guarantee.

[peternewman]

Hi @cho-m ,

Thanks for this. Hopefully it won't make a difference, but please can you also try for you with the additional tests in #2080 .

[peternewman]

I was a bit worried about ordering requirements for lower_bound, but it seems like that doesn't apply to multimap just other containers. Should we also check for upper_bound to be more efficient (potentially).

If it's insertion order, then:

a=1
b=0
a=5
c=42
d=11

We could avoid inspecting c or d presumably if we stop at the upper_bound of a?

It would definitely be good to add a slightly more complex test to cover that if so.

[aroffringa]

Suggested change

	for (iter = m_pref_map.lower_bound(key);
	iter != m_pref_map.end() && iter->first == key; ++iter) {
	values.push_back(iter->second);
	const std::pair<PreferencesMap::const_iterator, PreferencesMap::const_iterator> range = m_pref_map.equal_range(key);
	for (iter = range.first; iter != range.second; ++iter) {
	values.push_back(iter->second);

[aroffringa]

We could avoid inspecting c or d presumably if we stop at the upper_bound of a?

This is what equal_range() is for, which finds lower and upper bounds at once ; I've added a suggestion how to change that.