On Thu, Oct 10, 2019 at 08:00:53PM +0100, Richard Sandiford wrote:
> Ping
>
> Richard Sandiford <richard.sandif...@arm.com> writes:
> > The current aka diagnostics can sometimes leak internal details that
> > seem more likely to be distracting than useful. E.g. on aarch64:
> >
> > void f (va_list *va) { *va = 1; }
> >
> > gives:
> >
> > incompatible types when assigning to type ‘va_list’ {aka ‘__va_list’}
> > from type ‘int’
> >
> > where __va_list isn't something the user is expected to know about.
> > A similar thing happens for C++ on the arm_neon.h-based:
> >
> > float x;
> > int8x8_t y = x;
> >
> > which gives:
> >
> > cannot convert ‘float’ to ‘int8x8_t’ {aka ‘__Int8x8_t’} in initialization
> >
> > This is accurate -- and __Int8x8_t is defined by the AArch64 PCS --
> > but it's not going to be meaningful to most users.
Agreed.
> +/* Return true if it is worth exposing the DECL_ORIGINAL_TYPE of TYPE to
> + the user in diagnostics, false if it would be better to use TYPE itself.
> + TYPE is known to satisfy typedef_variant_p. */
> +
> +bool
> +user_facing_original_type_p (const_tree type)
> +{
> + gcc_assert (typedef_variant_p (type));
> + tree decl = TYPE_NAME (type);
> +
> + /* Look through any typedef in "user" code. */
> + if (!DECL_IN_SYSTEM_HEADER (decl) && !DECL_IS_BUILTIN (decl))
> + return true;
> +
> + /* If the original type is also named and is in the user namespace,
> + assume it too is a user-facing type. */
> + tree orig_type = DECL_ORIGINAL_TYPE (decl);
> + if (tree orig_id = TYPE_IDENTIFIER (orig_type))
> + {
> + const char *name = IDENTIFIER_POINTER (orig_id);
> + if (name[0] != '_' || (name[1] != '_' && !ISUPPER (name[1])))
> + return true;
This looks like name_reserved_for_implementation_p.
The rest looks fine to me!
--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA
