Почему при назначении копирования G CC выдает предупреждение -Wvirtual-move-assign?

Question

Следующая иерархия классов вызовет предупреждение [-Wvirtual-move-assign] в G CC, если присвоение перемещения вызывается для экземпляра B.

struct A {

    std::vector<int> v;

};

struct B : public virtual A {};

Следующий сценарий ios действительно вызывает предупреждение

/*** SCENARIO 1 ***/
class C {

    B a;

    public:
        void foo(B& b) {

            b = a; // warning
            // or
            a = b; // warning

        }

};

/*** SCENARIO 2 ***/
void foo(const B& a, B& b) {

    b = a; // warning

}


int main() {

    /*** SCENARIO 3 ***/
    B b;
    std::vector<B> v1;
    v1.push_back(b); // warning

    /*** SCENARIO 4 ***/
    B b1;
    B b2;
    b1 = b2; // warning

    /*** SCENARIO 5 ***/
    B b3;
    b3 = B(); // warning

}

Предупреждения по-прежнему появляются, даже если назначенный объект снова используется позже. За исключением Сценария 5, который включает в себя r-значение на правой стороне и, следовательно, будет включать в себя назначение перемещения, я ожидал (и действительно хочу), чтобы в этом сценарии происходило назначение копирования, а не перемещение, ios. Если это так, то почему возникает это предупреждение? Действительно ли где-то в выражениях происходит перемещение?

Answer 1

Похоже, вы попали в ложное срабатывание. Ответ на Почему g cc предупреждает о вызове нетривиального оператора назначения перемещения с использованием std :: tuple и виртуального наследования? предполагает, что g cc выдает это предупреждение чаще, чем это действительно необходимо, а этот лязг нет. Поэтому я усилил ваш пример (как было сделано в этом ответе) и передал его clang.

struct A {
    std::vector<int> v;
};

struct AA : public virtual A {};
struct AB : public virtual A {};

struct B : public AA, AB {};

При такой настройке clang предупреждает только для строки b3 = B(); (сценарий 5). Он принимает другой сценарий ios, предполагая, что g cc просто параноик. (Либо g cc выдает ложное срабатывание, либо у clang есть ошибка. Ваш анализ выглядит правильным, хотя, вероятно, и первый.)