Skip to content

Clang choosing copy constructor over initializer_list #58520

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
lkattha opened this issue Oct 21, 2022 · 6 comments
Closed

Clang choosing copy constructor over initializer_list #58520

lkattha opened this issue Oct 21, 2022 · 6 comments
Labels
c++ clang:frontend Language frontend issues, e.g. anything involving "Sema" confirmed Verified by a second party duplicate Resolved as duplicate

Comments

@lkattha
Copy link

lkattha commented Oct 21, 2022

The following short program returns '3' with clang, but '30' with GCC and '12' with MSVC.
The issue is that in lines (3) and (4), both the copy-constructor (1) and the initializer_list constructor (2) could be called.
According to cppreference.com, (2) should be called.
However, clang chooses (1) on both instances. (Interestingly, MSVC chooses (2) on (3) and (1) on (4).

This error also accurs if the constructor of S takes an initializer_list of another type T, which can be implicitly contructed from S, this is how I encountered the bug in real code.

#include <initializer_list>

struct S {
    S() = default;
    S(const S& other): i_(1) {} // (1)
    S(const std::initializer_list<S> args): i_(10) {} // (2)

    int i_;
};

struct T {
    //Clang: calls (1)
    //GCC, MSVC: calls (2)
    T(const S& s) : s_{s} {}       // (3)

    S s_;
};

int main() {
    S s;
    T t(s);

    //Clang, MSVC: calls  (1)
    //GCC: calls (2)
    S s2{s};        // (4)

    return t.s_.i_ + 2*s2.i_;
}
@lkattha lkattha changed the title CLang choosing copy constructor over initializer_list Clang choosing copy constructor over initializer_list Oct 21, 2022
@EugeneZelenko EugeneZelenko added clang:frontend Language frontend issues, e.g. anything involving "Sema" and removed new issue labels Oct 21, 2022
@llvmbot
Copy link
Member

llvmbot commented Oct 21, 2022

@llvm/issue-subscribers-clang-frontend

@shafik
Copy link
Collaborator

shafik commented Oct 21, 2022

This looks like DR 2137 which reverted the change from DR 1467 which is the behavior that we are currently implementing AFAICT.

The clang defect report status indicates we implemented 1467 but we have unknown status for 2137 (presumedly b/c we did not implement it).

@shafik shafik added confirmed Verified by a second party c++ labels Oct 21, 2022
@llvmbot
Copy link
Member

llvmbot commented Oct 21, 2022

@llvm/issue-subscribers-c-1

@Long5hot Long5hot self-assigned this Jul 25, 2023
@Long5hot
Copy link
Contributor

Long5hot commented Aug 9, 2023

i'd like to know if anyone started working on DR2137!
@shafik @AaronBallman

@AaronBallman
Copy link
Collaborator

i'd like to know if anyone started working on DR2137! @shafik @AaronBallman

There is a recent in-progress patch up for review at https://reviews.llvm.org/D156032

@zygoloid
Copy link
Collaborator

zygoloid commented Jan 9, 2024

Duplicate of #24186.

@zygoloid zygoloid closed this as not planned Won't fix, can't repro, duplicate, stale Jan 9, 2024
@EugeneZelenko EugeneZelenko added the duplicate Resolved as duplicate label Jan 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ clang:frontend Language frontend issues, e.g. anything involving "Sema" confirmed Verified by a second party duplicate Resolved as duplicate
Projects
None yet
Development

No branches or pull requests

7 participants