On 18 September 2015 at 20:38, Ville Voutilainen
<ville.voutilai...@gmail.com> wrote:
> On 18 September 2015 at 20:30, Ville Voutilainen
> <ville.voutilai...@gmail.com> wrote:
>> On 18 September 2015 at 20:26, Jason Merrill <ja...@redhat.com> wrote:
>>>>> I suppose so, but it seems pretty trivial. In any case, looks like your
>>>>> patch would accept the odd
>>>>> namespace A __attribute ((visibility ("default"))) ::B { }
>>>> Yes, or namespace A[[nonsense]]::B {}. Those cases are easy to fix,
>>>> but namespace [[attribute_in_proper_location]] A {} seemingly caused
>>>> weird barfing. That's why I didn't put in the rejection of the former, I'd
>>>> prefer
>>>> to figure out the latter and the former at the same time, and I'd prefer
>>>> doing
>>>> that once the basic facility is in. Yes, partly because I'll travel
>>>> tomorrow. :)
>>> To fix the former, you just need to keep
>>>> /* Parse any specified attributes. */
>>>> attribs = cp_parser_attributes_opt (parser);
>>> next to the open brace. OK with that change, I suppose the other can wait.
>>
>>
>> I also need to diagnose the use of attributes with a nested namespace
>> definition,
>> so I need to add the error emission and test it. ;)
>
> Hmm, I already do that, the nested namespace definition parsing
> effectively requires
> an identifier. Ok, I'll give it a spin, I'll send an updated patch for
> review. :)
Argh, no. An attribute immediately following a nesting namespace would need
to be parsed before the nested namespace definition handling is done, otherwise
the nested namespace definition handling is never entered because the next token
is not CPP_SCOPE. So the attributes should be parsed and rejected where they are
parsed now if they are followed by a CPP_SCOPE. That's easy, I'll just check
for non-null attribs and diagnose.
