On Wed, Oct 04, 2017 at 10:44:11AM -0400, Jason Merrill wrote:
> > 3) A couple of places do:
> > T (name // line break to avoid wrap
> > [LONGEXPR][OTHERLONGEXPR]);
> >
> > The parens aid the editor's formatter. The patch removes the parens, but I
> > can see there may be disagreement. I suppose we could permit parens at the
> > outermost declarator for an array?
> > Affects ira-int.h (target_ira_int::x_ira_reg_mode_hard_regset)
> > reload.h (target_reload::x_regno_save_mode)
>
> We could also check whether the declarator spans lines to detect this case.
I think it is better to just fix it up so that no line break is needed
there. E.g. define a macro, enum or const int with the sizes and use that
in the declaration.
> > 4) A set of typedef'd function types (NOT ptr-to-fn). The name being
> > typedef'd is parenthesized and not an idiom I recall seeing before. AFAICT
> > these are the only cases of typedefing a plain fn. We could, I suppose,
> > ignore parens on a typedef'd fntype, but that seems a little random.
> > Affects gengtype.c (frul_actionrout_t)
> > lto-streamer.h (lto_get_section_data_f & to_free_section_data_f)
> > tree-ssa-threadedge.c (pfn_simplify)
>
> Hmm, I don't think we want to diagnose these; if a parameter-list
> follows the parenthesized declarator, it isn't ambiguous.
>
> 3 and 4 seem like false positives. The problematic cases are all ones
> where the parenthesized name is at the end of the declarator; if the
> declarator continues after the name, either within or without the
> parens, this
>
> > Jason, do you have concerns about the C++ patch itself?
>
> Nope.
Jakub
