[Bug c++/25663] New: [4.1/4.2 Regression] Parses operator() call as declarator

[Bug c++/25663] New: [4.1/4.2 Regression] Parses operator() call as declarator

[rguenth at gcc dot gnu dot org]

The following is rejected now as of a change between r109062 and r109079
with "error: invalid declarator" on the 2nd last line.

template <class T>
struct ScalarCode
{
 ScalarCode(const T&);
 template <class A, class B>
 void operator()(const A&, const B&);
};
template <int Dim>
struct CflFunctor
{
 CflFunctor(bool omrot, bool vis_f);
};
struct Bar {};
void foo(bool omrot, bool vis_f, const Bar& x, const Bar& y)
{
 ScalarCode<CflFunctor<3> >(CflFunctor<3>(omrot, vis_f))(x, y);
}


-- 
           Summary: [4.1/4.2 Regression] Parses operator() call as
                    declarator
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Parses operator() call as declarator

[reichelt at gcc dot gnu dot org]

------- Comment #1 from reichelt at gcc dot gnu dot org  2006-01-04 12:07 -------
Confirmed.
The call to operator() is not the problem, though, as the following shorter
testcase shows:

==========================
template<int> struct A
{
  A(int);
};

void foo()
{
  A<0>(A<0>(0));
}
==========================

This also affects the 4.0 branch. This is a regression from 4.0.2!


-- 

reichelt at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |reichelt at gcc dot gnu dot
                   |                            |org
           Severity|normal                      |critical
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |monitored
   Last reconfirmed|0000-00-00 00:00:00         |2006-01-04 12:07:30
               date|                            |
            Summary|[4.1/4.2 Regression] Parses |[4.0/4.1/4.2 Regression]
                   |operator() call as          |Parses operator() call as
                   |declarator                  |declarator
   Target Milestone|---                         |4.0.3


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2006-01-04 12:10 -------
Using

  (ScalarCode<CflFunctor<3> >(CflFunctor<3>(omrot, vis_f)))(x, y);

was a workaround for me, so I thought it indeed was the issue...  maybe there
are two issues actually.


-- 


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2006-01-04 12:11 -------
Adding Mark in CC, because he caused this regression.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[reichelt at gcc dot gnu dot org]

------- Comment #4 from reichelt at gcc dot gnu dot org  2006-01-04 12:21 -------
> Using
>
>   (ScalarCode<CflFunctor<3> >(CflFunctor<3>(omrot, vis_f)))(x, y);
>
> was a workaround for me, so I thought it indeed was the issue...

Adding parens in my example also makes the bug go away:
  (A<0>(A<0>(0)));

We couldn't parse this before 3.4.0 either.
We try to parse this as a declaration instead of a constructor call.
With the parens we don't try to parse this as a declaration and
everything goes well.

> maybe there are two issues actually.

I don't think so.


-- 


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[mark at codesourcery dot com]

------- Comment #5 from mark at codesourcery dot com  2006-01-14 04:56 -------
Subject: Re:  [4.0/4.1/4.2 Regression] Trouble parsing nested
 templated constructor calls

Richard --

First, please respect my request that only the RM set priority fields
for bugs.  Therefore, please set this back to P3, until I have time to
look at it.

Second, please give me some time to look at; I've just returned from a
one-week offsite.  I've not forgotten about this issue.


-- 


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-01-14 05:58 -------
(In reply to comment #5)
> Second, please give me some time to look at; I've just returned from a
> one-week offsite.  I've not forgotten about this issue.

Only two other maintainers of C++ have to say that this patch can be reverted
(this is the rule which is in http://gcc.gnu.org/develop.html).

And the 48 hours have elapsed already:

If a patch is committed which introduces a regression on any target which the
Steering Committee considers to be important and if:

the problem is reported to the original poster;
48 hours pass without the original poster or any other party indicating that a
fix will be forthcoming in the very near future;
two people with write privileges to the affected area of the compiler determine
that the best course of action is to revert the patch;
then they may revert the patch.


-- 


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2006-01-14 10:55 -------
(ignoring Pinskias valid but not helpful comments)

Sorry Mark, it was not meant as a personal offense, but as you asked for a
testcase in the first place and did not respond to me after providing one
and after filing this bug the only conclusion I could come to was that you
didn't care about this particular regression (with tramp3d being the only
fallout I noticed).

I have reverted the priority to P3.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[steven at gcc dot gnu dot org]

------- Comment #8 from steven at gcc dot gnu dot org  2006-01-14 12:22 -------
Mark,

Re. your comment #5, I think everyone respects your request that only the RM
sets priorities.  But right now the RM fails to do so.

I have also set priorities on a number of bugs that obviously have the wrong
priority setting.  Some bugs are not relevant at all, e.g. not a primary or
secondary platform, or for a language that is not release critical.  Other bugs
are obvious must-fix bugs, or at least must-analyze, before 4.1 can go out the
door.  I've adjusted priorities on roughly one dozen bugs in the last week
alone when it was obvious that the bug has the wrong priority.

If you think that is wrong, you should just go over the list of bugs more often
and set the priorities yourself.  I am sure you're a very busy man, but if you
want everyone to stop touching bug priorities, then you have the responsibility
to set them for us, and you will just have to find the time to do so or relax
the rules again.

In this case, you don't comment at all on a regression that you caused, until
Richard escalates the issue and sets the priority higher himself. Richard
reported the problem 12 days ago today.  Do you think it is strange that people
get annoyed with you if you cause regressions and then essentially disappear
for 12 days?  Had it been someone else instead of you who caused this bug,
people would have reverted the patch causing this bug long ago.


-- 


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[mark at codesourcery dot com]

------- Comment #9 from mark at codesourcery dot com  2006-01-14 18:44 -------
Subject: Re:  [4.0/4.1/4.2 Regression] Trouble parsing nested
 templated constructor calls

rguenth at gcc dot gnu dot org wrote:
> ------- Comment #7 from rguenth at gcc dot gnu dot org  2006-01-14 10:55 -------
> (ignoring Pinskias valid but not helpful comments)
> 
> Sorry Mark, it was not meant as a personal offense

No offense taken!

> I have reverted the priority to P3.

Thanks,


-- 


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[mark at codesourcery dot com]

------- Comment #10 from mark at codesourcery dot com  2006-01-14 18:48 -------
Subject: Re:  [4.0/4.1/4.2 Regression] Trouble parsing nested
 templated constructor calls

steven at gcc dot gnu dot org wrote:
> ------- Comment #8 from steven at gcc dot gnu dot org  2006-01-14 12:22 -------
> Mark,
> 
> Re. your comment #5, I think everyone respects your request that only the RM
> sets priorities.  But right now the RM fails to do so.

I think that's an overly strong statement.  I try to make a pass over
the open bugs every few weeks.  But, I will try to increase the
frequency at which I do this.

> In this case, you don't comment at all on a regression that you caused, until
> Richard escalates the issue and sets the priority higher himself. Richard
> reported the problem 12 days ago today.  Do you think it is strange that people
> get annoyed with you if you cause regressions and then essentially disappear
> for 12 days?  

I wish I'd been able to fix this more quickly, but there are certainly
other regressions that have been open longer than 12 days.

> Had it been someone else instead of you who caused this bug,
> people would have reverted the patch causing this bug long ago.

I don't think that's true; it's not that critical of a bug.  However, we
do have a process in place for reversions, and it's certainly reasonable
to invoke that process if you think that's appropriate.  In this case,
however, it looked like Richard was not aware of the process.


-- 


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[mmitchel at gcc dot gnu dot org]

------- Comment #11 from mmitchel at gcc dot gnu dot org  2006-01-15 00:56 -------
Subject: Bug 25663

Author: mmitchel
Date: Sun Jan 15 00:56:50 2006
New Revision: 109713

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109713
Log:
        PR c++/25663
        * parser.c (cp_parser_direct_declarator): Use cp_parser_error
        instead of error.
        PR c++/25663
        * g++.dg/template/ctor6.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/template/ctor6.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/parser.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[mmitchel at gcc dot gnu dot org]

------- Comment #12 from mmitchel at gcc dot gnu dot org  2006-01-15 00:57 -------
Subject: Bug 25663

Author: mmitchel
Date: Sun Jan 15 00:57:22 2006
New Revision: 109714

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109714
Log:
        PR c++/25663
        * parser.c (cp_parser_direct_declarator): Use cp_parser_error
        instead of error.
        PR c++/25663
        * g++.dg/template/ctor6.C: New test.

Added:
    branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/ctor6.C
Modified:
    branches/gcc-4_1-branch/gcc/cp/ChangeLog
    branches/gcc-4_1-branch/gcc/cp/parser.c
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[mmitchel at gcc dot gnu dot org]

------- Comment #13 from mmitchel at gcc dot gnu dot org  2006-01-15 00:57 -------
Subject: Bug 25663

Author: mmitchel
Date: Sun Jan 15 00:57:47 2006
New Revision: 109715

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109715
Log:
        PR c++/25663
        * parser.c (cp_parser_direct_declarator): Use cp_parser_error
        instead of error.
        PR c++/25663
        * g++.dg/template/ctor6.C: New test.

Added:
    branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/ctor6.C
Modified:
    branches/gcc-4_0-branch/gcc/cp/ChangeLog
    branches/gcc-4_0-branch/gcc/cp/parser.c
    branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls

[mmitchel at gcc dot gnu dot org]

------- Comment #14 from mmitchel at gcc dot gnu dot org  2006-01-15 00:59 -------
Fixed in 4.0.3.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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