C++ parser issue [templ.res]

C++ parser issue [templ.res]

[Jan Van Dijk]

	Hi,

In spite of reading all of 14.6 [temp.res] repeatedly, I am still
in doubt whether the new parser correctly deals with the code
below or not. Since a week or two gcc-head refuses to compile D<T>::bad(),

gcctest.cpp: In member function `void D<T>::bad()':
gcctest.cpp:12: error: `i' has not been declared

Qualifying i as B<T>::i (thus making i a dependent name explicitly)
fixes the problem, see ugly(). To my surprise, look up of member
variables is now different from that of member functions: f() does
not need to be qualified (see good()). Either I missed a crucial 
section of the standard (which one?), or this is a parser bug.

I checked gcc/cp/NEWS and other sources to see an announcement of this
change (making it intentional), but did not recognize anything relevant.

Thanks for your time,

	Regards, Jan van Dijk

template <class T>
struct B 
{
	int i;
	int f();
};

template <class T>
struct D : public B<T> 
{
	void good(){ f(); }		// no B<T>:: required
	void bad(){ i=0; }			// does not compile with `head',
	void ugly(){ B<T>::i=0; }	// ... this does.
};

-- 
Keio-Tsuushin Residence
Jan van Dijk, Room 210
2 Chome 19-30, Mita Minato-ku
108 Tokyo, Japan

jan@etpmod.phys.tue.nl
tel: +81 3 5476 9461 (home)

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!  http://bb.yahoo.co.jp/

Re: C++ parser issue [templ.res]

[Gabriel Dos Reis]

Jan Van Dijk <janvandijkinjapan@yahoo.co.jp> writes:

[...]

| Qualifying i as B<T>::i (thus making i a dependent name explicitly)
| fixes the problem, see ugly(). To my surprise, look up of member
| variables is now different from that of member functions: f() does
| not need to be qualified (see good()). Either I missed a crucial 
| section of the standard (which one?), or this is a parser bug.
| 
Parser bug.

-- Gaby

Re: C++ parser issue [templ.res]

[Nathan Sidwell]

Jan Van Dijk wrote:

refer to 14.6/8 in your example both i and f are non-dependent names
so the usual lookup rules apply. 3.4.1, 3.4.2. 3.4.1 deals with
non-function call unqualified name lookup (i), and 3.4.2 deals with
unqualified names used for function calls. That uncludes koenig
lookup. In this case there are no template-dependent arguments, so
the koenig lookup should be resolved at parse time. (see example
in 14.6/9)

> template <class T>
> struct B 
> {
> 	int i;
> 	int f();
> };
> 
> template <class T>
> struct D : public B<T> 
> {
> 	void good(){ f(); }		// no B<T>:: required
If you said &f;, you'd get the same error. I think this is a bug,
please file a bug report.

> 	void bad(){ i=0; }			// does not compile with `head',
> 	void ugly(){ B<T>::i=0; }	// ... this does.
> };
> 

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: C++ parser issue [templ.res]

[Mark Mitchell]

--On Tuesday, January 28, 2003 05:03:00 PM +0000 Jan Van Dijk 
<janvandijkinjapan@yahoo.co.jp> wrote:

> 	void good(){ f(); }		// no B<T>:: required

I *think* this is a parser bug; i.e., this should be an error.

The question is whether any of the arguments to the function is
dependent.  Since we are in a non-static member function, a key
question is whether the "this" parameter should be included, but
I think not.

Would you please file a PR?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C++ parser issue [templ.res]

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| --On Tuesday, January 28, 2003 05:03:00 PM +0000 Jan Van Dijk
| <janvandijkinjapan@yahoo.co.jp> wrote:
| 
| > 	void good(){ f(); }		// no B<T>:: required
| 
| I *think* this is a parser bug; i.e., this should be an error.
| 
| The question is whether any of the arguments to the function is
| dependent.  Since we are in a non-static member function, a key
| question is whether the "this" parameter should be included, but
| I think not.

"f()" in the above expression is neither a type-dependent expression
nor a value-dependent expression 14.6.2/1:

  [...] Expressions may be type-dependent (on the type of a tem-plate
  parameter) or value-dependent (on the value of a non-type template
  parameter). In an expression of the form: 

      postfix-expression ( expression-list opt ) 

  where the postfix-expression is an identifier, the identifier
  denotes a dependent name if and only if any of the expressions in
  the expression-list is a type-dependent expression (14.6.2.2). 

therefore 14.6.3/1 applies.

-- Gaby

Re: C++ parser issue [templ.res]

[Jan Van Dijk]

On Tuesday 28 January 2003 19:19, Gabriel Dos Reis wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> | --On Tuesday, January 28, 2003 05:03:00 PM +0000 Jan Van Dijk
> |
> | <janvandijkinjapan@yahoo.co.jp> wrote:
> | > 	void good(){ f(); }		// no B<T>:: required
> |
> | I *think* this is a parser bug; i.e., this should be an error.
> |
> | The question is whether any of the arguments to the function is
> | dependent.  Since we are in a non-static member function, a key
> | question is whether the "this" parameter should be included, but
> | I think not.
>
> "f()" in the above expression is neither a type-dependent expression
> nor a value-dependent expression 14.6.2/1:
>
>   [...] Expressions may be type-dependent (on the type of a tem-plate
>   parameter) or value-dependent (on the value of a non-type template
>   parameter). In an expression of the form:
>
>       postfix-expression ( expression-list opt )
>
>   where the postfix-expression is an identifier, the identifier
>   denotes a dependent name if and only if any of the expressions in
>   the expression-list is a type-dependent expression (14.6.2.2).
>
> therefore 14.6.3/1 applies.

OK, I did some more homework. A few possible issues (and an ICE) remain. 
Consider:

template <class T> struct B { int i; };
template <class T> struct D : public B<T>
{
        // D<T> and B<T> are dependent: OK
        void i1() { D<T>::i=0; }
        void i2() { B<T>::i=0; }
        // 14.6.2.2/2: `this' is inside i3(), enclosing class dependent.
	// Hence this is dependent. It is part of the expression: OK.
        void i3() { this->i=0; }

        // this should not compile, and doesn't: OK
        void i4() { i=0; }

        // 3.4.1/2 does not work here: this does not compile. Why?
        using B<T>::i;
        void i5() { i=0; }
        // and this causes an ICE:
        void i6() { using B<T>::i; i=0; }
};

OK, so gcc (HEAD,yesterday) now correctly compiles i1(), i2() and i3(), and 
correctly refuses i4(). But is it correct that i5() does not compile? I would 
think that 3.4.1/2 (using directive) would work as usual. It would bring i in 
scope, and from the using statement (using B<T>::i) it is obvious that i is a 
dependent name. Hence i5() seems correct, apart from the semantics it would 
be no different from i2(). The same goes for i6(), but that even causes an 
ICE:

t.cpp:17: internal compiler error: in validate_nonmember_using_decl, at
   cp/decl2.c:4152

which is obviously not good behaviour.

As a side note: it is frustrating that the intuitive form (plain `i=0;' in the 
derived class) does not work, while the seamingly equivalent `this->i' is OK. 
More precisely, it is counter-intuitive that the interpretation of the name 
(i) is _delayed_ by adding _more_ information about the namespace where it 
can be found. I'm sure this has been anticipated by the standard committee, 
and assume  there is a good reason for this behaviour. 

A pointer to additional reading would be appreciated, though. (Otherwise I'll 
wait for the next edition of the D&E of C++). I guess a lot of people who use 
templated class hierarchies are going to be unpleasantly surprised by the 
superb quality of gcc-3.4. A note or such a pointer in gcc/cp/NEWS could 
perhaps help?

	With kind regards, Jan van Dijk.

-- 
Keio-Tsuushin Residence
Jan van Dijk, Room 210
2 Chome 19-30, Mita Minato-ku
108 Tokyo, Japan

jan@etpmod.phys.tue.nl
tel: +81 3 5476 9461 (home)

__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!  http://bb.yahoo.co.jp/

Re: C++ parser issue [templ.res]

[Richard Guenther]

Jan Van Dijk wrote:

<quote>

OK, I did some more homework. A few possible issues (and an ICE) remain.
Consider:

template <class T> struct B { int i; };
template <class T> struct D : public B<T>
{
        // D<T> and B<T> are dependent: OK
        void i1() { D<T>::i=0; }
        void i2() { B<T>::i=0; }
        // 14.6.2.2/2: `this' is inside i3(), enclosing class dependent.
	// Hence this is dependent. It is part of the expression: OK.
        void i3() { this->i=0; }

        // this should not compile, and doesn't: OK
        void i4() { i=0; }

        // 3.4.1/2 does not work here: this does not compile. Why?
        using B<T>::i;
        void i5() { i=0; }
        // and this causes an ICE:
        void i6() { using B<T>::i; i=0; }
};

OK, so gcc (HEAD,yesterday) now correctly compiles i1(), i2() and i3(),
and
correctly refuses i4(). But is it correct that i5() does not compile? I
would
think that 3.4.1/2 (using directive) would work as usual. It would bring i
in
scope, and from the using statement (using B<T>::i) it is obvious that i
is a
dependent name. Hence i5() seems correct, apart from the semantics it
would
be no different from i2(). The same goes for i6(), but that even causes an
ICE:

t.cpp:17: internal compiler error: in validate_nonmember_using_decl, at
   cp/decl2.c:4152

which is obviously not good behaviour.

<endquote>

These are c++/9432 (ICE) and c++/9447 (not working using directive).

Richard.

--
Richard Guenther <richard.guenther@uni-tuebingen.de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/