public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "igodard at pacbell dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/12672] New: Evals template defaults args that it should not
Date: Sat, 18 Oct 2003 08:24:00 -0000	[thread overview]
Message-ID: <20031018082407.12672.igodard@pacbell.net> (raw)

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672

           Summary: Evals template defaults args that it should not
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: igodard at pacbell dot net
                CC: gcc-bugs at gcc dot gnu dot org

The compiler tries to evaluate template default arguments on a result type of an overloaded call on a template function for an overload that cannot be the correct candidate. 

The actual call has two args, and the templated overload with two formals is the target of the call. However, there is also a templated overload with only one argument. That one-arg function has a result type which is itself a template with default args. The compiler tries to evaluate the default args for the type of the template and it blows up because it's undefined for that type.

The problem seems to be that the compiler is not first pruning all candidates with the wrong number of formals before doing type matching. These candidates cannot be the matching overload because they have the wrong number of args. So the compiler is trying to do type matching on impossible overloads, and if that matching (correctly) gets in trouble then you get an error, whereas if arg-number pruning were first then you would get a correct match and no error.

The particular error in the test case is that the evaluation of a default template argument of a type used by the function calls for a member type that doesn't exist for the actual type. However, the actual error in the test doesn't matter - anything that would cause an error during type matching on the wrong (impossible) overload would do.


             reply	other threads:[~2003-10-18  8:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-18  8:24 igodard at pacbell dot net [this message]
2003-10-18  8:26 ` [Bug c++/12672] " igodard at pacbell dot net
2003-10-18 11:28 ` igodard at pacbell dot net
2003-10-18 16:19 ` pinskia at gcc dot gnu dot org
2003-10-18 19:50 ` bangerth at dealii dot org
2003-12-28 22:13 ` pinskia at gcc dot gnu dot 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=20031018082407.12672.igodard@pacbell.net \
    --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).