Re: [C++ Patch] Fix some locations

[Jason Merrill <jason at redhat dot com>]

On Fri, Jun 1, 2018 at 5:03 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> while working on some bugs I noticed that in a few places in decl.c we could
> do better in terms of locations within the current infrastructure, some
> simple, straightforward improvements. I'm attaching below a tiny first
> patch, more to follow, I hope.
>
> For example, a function which could be improved in many places is
> grok_ctor_properties and, before going ahead, I'd like to ask about
> something I noticed yesterday:
>
>   /* There can be no default arguments.  */
>   for (tree arg = argtypes; arg != void_list_node; arg = TREE_CHAIN (arg))
>     if (TREE_PURPOSE (arg))
>       {
>         TREE_PURPOSE (arg) = NULL_TREE;
>         if (operator_code == POSTINCREMENT_EXPR
>             || operator_code == POSTDECREMENT_EXPR)
>           pedwarn (input_location, OPT_Wpedantic,
>                    "%qD cannot have default arguments", decl);
>         else
>           {
>             error ("%qD cannot have default arguments", decl);
>             return false;
>           }
>       }
>
> the special casing seems weird, so far I haven't been able to find anything
> in the standard about it and all the other compilers I have at hand (Oracle,
> Intel, Clang) don't seem to have it. Shall we keep it or not? Maybe with an
> additional comment explaining the rationale? The affected testcases would be
> parse/defarg11.C and g++.jason/operator.C.

I think in the olden days, with a default argument one function could
support both prefix and postfix inc/decrement syntax:

struct A {
  A& operator++(int = 0);
};

int main()
{
  A a;
  ++a;
  a++;
}

...but that hasn't actually worked in forever, so it shouldn't be a
problem to make the ++ case an error, too.

Jason