This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA (libstdc++): C++/v3 PATCH for c++/24163 (lookup in dependent bases) and c++/29131
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>, Benjamin Kosnik <bkoz at redhat dot com>, "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Fri, 20 May 2011 12:01:15 -0500
- Subject: Re: RFA (libstdc++): C++/v3 PATCH for c++/24163 (lookup in dependent bases) and c++/29131
- References: <4DD69790.8070101@redhat.com>
On Fri, May 20, 2011 at 11:32 AM, Jason Merrill <jason@redhat.com> wrote:
> G++ has had a long-standing bug with unqualified name resolution in
> templates: if we didn't find any declaration when looking up a name in the
> template definition, we would do an additional unqualified lookup at the
> point of instantiation. ?This led to incorrectly finding namespace-scope
> functions declared later (29131) and member functions of dependent bases
> (24163). ?This patch fixes that bug.
Ah, I had always assumed that the previous implementation was exploiting
a license given by the standard which says that both contexts should
yield the same resolution, otherwise the program was ill-formed, no diagnostic
required.
>
> To be friendly to users, the patch also allows affected code to compile with
> -fpermissive and provides suggestions about how to fix the code: either
> declaring the desired function earlier (29131) or explicitly qualifying the
> name with this-> or Class:: (24163).
>
> This caused a lot of regressions in the libstdc++ testsuite, which I've
> fixed. ?To find names in dependent bases, I've added explicit this-> in
> non-static member functions, and explicit Class:: in static member
> functions. ?I'd like confirmation from the library folks that this is the
> style they want to use for this.
>
> There were also a couple of issues with calls to functions that hadn't been
> declared yet; library folks should definitely check my formatting on the
> forward declarations I've added, for mem_fn in functional and for
> __expint_E1 in exp_integral.tcc.
>
> Tested x86_64-pc-linux-gnu. ?Are the library changes OK for trunk?
>
OK.
-- Gaby