This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] PR c++/65923
- From: Jason Merrill <jason at redhat dot com>
- To: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 4 Apr 2018 10:42:34 -0400
- Subject: Re: [C++ PATCH] PR c++/65923
- References: <CAFk2RUYBekRb4HMyLdUM3xryWPmdyvAAGxiRe01m1ErdE-HxUA@mail.gmail.com> <CAFk2RUb8s5Wt=_78OE97NFc4TQ54jOyDyKz+xeKT4RpOujmQvQ@mail.gmail.com>
On Wed, Apr 4, 2018 at 10:35 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 3 April 2018 at 17:19, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>> * parser.c (cp_parser_unqualified_id): Add a new parameter
>> and check it for the literal diagnostic.
>
>
> As discussed on irc, we can indeed do better. With this approach, we look at function declarations
> only, so using-declarations are automatically ok, and we allow friend declarations (that are not
> definitions) and local declarations. Tested locally/partially on Linux-x64, will test with the full suite
> if this is ok. On that front.. ..where can this land? This isn't a regression, but it's certainly a long-standing
> annoyance, but mostly only for -Werror users. I can argue it both ways.
> + if (suffix[0] != '_' && !in_system_header_at (input_location)
This should use DECL_SOURCE_LOCATION (decl) rather than
input_location. With that change, this seems safe enough for 8.
Jason