{"push_id":1070456766,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"fd39f9d7f8455454a0af259b2f925ea55e35fea2","before":"70fae264e38b9d898d3726f366e4e2da020edaa8","commits":[{"sha":"fd39f9d7f8455454a0af259b2f925ea55e35fea2","author":{"email":"a6a61c546febb48d516c1ffb86e1fe523686c40b@yahoo.com","name":"Faisal Vali"},"message":"Implement CWG 941 - explicit specializations of deleted function templates\n\n  template<class T> void f(T) = delete;\n  template<> void f(int); // OK.\n\n  f(3); // OK\n\nImplementation strategy:\n\nWhen an explicit specialization of a function template, a member function template or a member function of a class template is declared, clang first implicitly instantiates the declaration of a specialization from the templated-entity being explicitly specialized (since their signatures must be the same) and then links the explicit specialization being declared as a redeclaration of the aforementioned specialization.  \n\nThe problem was that when clang 'implicitly instantiates' the initial specialization, it marks the corresponding FunctionDecl as deleted if the corresponding templated-entity was deleted, rather than waiting to see whether the explicit specialization being declared provides a non-deleted body. (The eager marking of delete has advantages during overload resolution I suppose, where we don't have to try and instantiate a definition of the function to see if it is deleted). \n\nThe present fix entails recognizing that when clang knows that an explicit specialization is being declared (for whichever templated-entity), the prior implicit instantiation should not inherit the 'deleted' status, and so we reset it to false.\n\nI suppose an alternative fix (amongst others) could consider creating a new context (ExplicitSpecializationDeclarationSubstitution or some such) that is checked during template-argument-deduction and final substitution, and avoid inheriting the deleted status during declaration substitution.  But while conceptually cleaner, that would be a slightly more involved change (as could be some of the other alternatives: such as avoid tagging implicit specializations as deleted, and check their primary templates for the deleted status where needed), and so I chose a different path.  Hopefully it'll prove to not be a bad choice.\n\n\n\ngit-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266561 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/llvm-beanz/clang/commits/fd39f9d7f8455454a0af259b2f925ea55e35fea2"}]}