librbd: workaround an ICE of GCC

GCC is somehow annoyed at seeing the combination of decltype and
initializer_list in this place. i tried to remove the `if` clause, and
only left the `else` block, GCC was happy with that change. i also tried
to pass an empty `{}` to `decltype(reply.lockers)`, and GCC was also
happy with that. so i guess there are multiple factors taking effect in
this problem. probably any of them could be the last straw that breaks
GCC.

but we cannot have a minimal reproducer for this issue here without more
efforts. and `reply.lockers` is empty after `reply` is constructed, so
it would be simpler if we just add the locker info to it instead of
assigning a newly constructed `map` to it.

Fixes: http://tracker.ceph.com/issues/37719
Signed-off-by: Kefu Chai <kchai@redhat.com>

1 files changed, 3 insertions, 3 deletions

diff --git a/src/test/librbd/managed_lock/test_mock_GetLockerRequest.cc b/src/test/librbd/managed_lock/test_mock_GetLockerRequest.cc
index 627de21cd8f..69e987e4d09 100644
--- a/src/test/librbd/managed_lock/test_mock_GetLockerRequest.cc
+++ b/src/test/librbd/managed_lock/test_mock_GetLockerRequest.cc
@@ -62,9 +62,9 @@ public:
 
       cls_lock_get_info_reply reply;
       if (r != -ENOENT) {
-        reply.lockers = decltype(reply.lockers){
-          {rados::cls::lock::locker_id_t(entity, locker_cookie),
-           rados::cls::lock::locker_info_t(utime_t(), entity_addr, "")}};
+        reply.lockers.emplace(
+          rados::cls::lock::locker_id_t(entity, locker_cookie),
+          rados::cls::lock::locker_info_t(utime_t(), entity_addr, ""));
         reply.tag = lock_tag;
         reply.lock_type = lock_type;
       }