On 08/03/2016 02:01 PM, Jason Merrill wrote:
On Wed, Aug 3, 2016 at 3:10 PM, Martin Sebor <mse...@gmail.com> wrote:
Do you have ideas about how to improve the naming?  Perhaps change
TYPE_ANONYMOUS_P to TYPE_NO_LINKAGE_NAME?

I haven't thought about changing names but TYPE_NO_LINKAGE_NAME
seems better than TYPE_ANONYMOUS_P.

Or perhaps TYPE_UNNAMED_P.

TYPE_UNNAMED_P would work but it wouldn't be a replacement for
TYPE_ANONYMOUS_P.

It sounds like TYPE_ANONYMOUS_P is the right name and the problem
is that the value it returns isn't accurate until the full context
to which it applies has been seen.

I think you're thinking of ANON_AGGR_TYPE_P, which identifies
anonymous structs/unions; TYPE_ANONYMOUS_P identifies unnamed classes.

Doh!  You're right.  I let the name confuse me again. Clearly
TYPE_ANONYMOUS_P isn't the best name since it doesn't correspond
to the C/C++ concept of an anonymous struct or union.  TYPE_UNNAMED
would be better (the same can be said about the C++ diagnostics that
refer to unnamed structs as <anonymous struct>.)


I wonder if the right solution to this class of problems (which
are probably unavoidable in the front end as the tree is being
constructed), is to design an API that prevents using these
"unreliable" queries until they can return a reliable result.

It would be possible to change ANON_AGGR_TYPE_P to require
COMPLETE_TYPE_P, but a lot of uses will need to be adjusted to avoid
crashing.

No, crashing shouldn't happen.  It shouldn't be possible to call
the function unless/until the node that represents the concept
has been fully constructed. Using C++ syntax:

  void foo (tree *t)
  {
    if (ANONYMOUS_STRUCT *anon = dynamic_cast<ANONYMOUS_STRUCT*>(t))
      anon->function_only_defined_in_anonymous_struct ();
  }

I was hoping something like this was close to what someone (Andrew?)
has been working on.

Martin

Reply via email to