public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/91133] [8/9/10/11 Regression] Wrong "partial specialization is not more specialized than" error
Date: Fri, 01 May 2020 17:15:53 +0000	[thread overview]
Message-ID: <bug-91133-4-gun6olTvxd@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-91133-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91133

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> ---
This is really a question of partial ordering; determining whether the partial
specialization is more specialized than the primary class template is
equivalent to this testcase:

template<typename T> struct Id { typedef T type; };
template<typename T, typename U, U X> struct A {};

template<typename T, typename U, U X>        void f(A<T, U,   X>); // #1
template<typename T, typename Id<T>::type X> void f(A<T, int, X>); // #2

int main()
{
  f(A<int,int,42>()); // is #2 more specialized?
}

This was rejected as ambiguous by GCC going back at least to 4.1.  It is also
rejected by EDG/icc.  It is accepted by clang and msvc, like the original
testcase.

The issue is with the partial ordering deduction of #1 from #2: we deduce int
for U from the second argument, and Id<T>::type for U from the third argument,
and those don't agree, so deduction for the third argument fails in both
directions, and the functions are ambiguous.

This is related to open core issues 455 and 1337.

I don't know what rationale clang/msvc are using to conclude that #2 is more
specialized.

  parent reply	other threads:[~2020-05-01 17:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-91133-4@http.gcc.gnu.org/bugzilla/>
2020-04-30 20:46 ` jason at gcc dot gnu.org
2020-05-01 17:15 ` jason at gcc dot gnu.org [this message]
2021-05-14  9:51 ` [Bug c++/91133] [9/10/11/12 " jakub at gcc dot gnu.org
2021-06-01  8:14 ` rguenth at gcc dot gnu.org
2022-05-27  9:41 ` [Bug c++/91133] [10/11/12/13 " rguenth at gcc dot gnu.org
2022-06-28 10:37 ` jakub at gcc dot gnu.org
2023-03-16 17:07 ` jason at gcc dot gnu.org
2023-07-07 10:35 ` [Bug c++/91133] [11/12/13/14 " rguenth at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-91133-4-gun6olTvxd@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).