This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++1y] [PATCH 3/4] ... canonical type workaround and refactoring

On 23.09.2013 08:15, Adam Butcher wrote:
On 22.09.2013 18:57, Adam Butcher wrote:
The following solves the canonical type issue in the general case
(pointers and refs) and makes it equivalent to the explicit template
case -- in terms of canonical type at least.

for (tree t = TREE_TYPE (TREE_VALUE (p)); t; t = TREE_CHAIN (t))
        TYPE_CANONICAL (t) = t;

The above is insufficient; the traversal doesn't handle function
pointers.  Currently, to get my local testcases passing, I have the
following workaround that abuses find_type_usage.  I intend for this
to be replaced with a better solution but it will at least mean that
people can start experimenting with this feature now (as they appear
to be doing  This
supports that testcase also.

Shall I push the patch below to trunk as an intermediate workaround whilst I get to refactoring to support on-the-fly template parm synthesis?

On the subject of on-the-fly synthesis: I haven't started yet but I'm thinking to trigger in 'cp_parser_simple_type_specifier' when 'current_binding_level->kind == sk_function_parms'. I can foresee a potential issue with packs in that, upon reading the 'auto' (potentially nested in some other type), a plain template parm will be synthesized; but it may need to be a pack parm type if '...' is found later.

My initial testcase is:

  template <typename T> struct X { T m(int, float); };

  auto f(X<auto>, auto (X<auto>::*) (auto...))
     char* s = "warn";

  int main()
     X<char> x;
     f(x, &X<void>::m);

where f should be translated as similar to:

  template <typename A1, typename A2, typename A3,
            typename... A4>
  auto f(X<A1>, A2 (X<A3>::*) (A4...))
     char* s = "warn";

In the case of something like:

  auto f(X<auto>&&...)

the translation would need to be:

  template <typename... A>
  auto f(X<A>&&...)

I'm thinking that getting that to happen correctly might be tricky (but haven't tried yet). The 'auto' would trigger plain template parameter synthesis. Perhaps a 'could_be_parameter_pack_p' on the template_type_parm? Though I don't know how the following could be handled as implicit

  template <typename T, typename A...>
  auto f(X<T, A>&&...)

It would not be possible to infer which of the template parms to make the pack.

  auto f(X<auto, auto>&&...)

Probably multiple generic-type pack expansions should be forbidden.

I'll see what happens when I get there but any guidance/thoughts you have on the subject will be valuable.


Workaround implicit function template parameter canonical type issue.

        * parser.c (add_implicit_template_parms): Workaround to fix
up canonical
type references left over from before substation of 'auto'. Better
        solution needed but this makes test cases functional.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index f3133f3..4171476 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -28987,6 +28987,25 @@ add_implicit_template_parms (cp_parser
*parser, size_t expect_count,
       if (!generic_type_ptr)

+ /* Make the canonical type of each part of the parameter distinct. + FIXME: A better solution is needed for this. Not least the abuse of + find_type_usage. Need foreach_type or similar for proper mutable
+        access.  If something like this does turn out to be
necessary then the
+        find_type_usage loop above can be replaced by a foreach_type
that fixes
+        up the canonical types on the way to finding the 'auto'.  */
+      struct helper { static bool fixup_canonical_types (tree t) {
+         t = TREE_TYPE (t);
+         if (!t)
+           return false;
+         if (is_auto_or_concept (t))
+           return true;
+         TYPE_CANONICAL (t) = t;
+         return false;
+      }};
+      find_type_usage (TREE_VALUE (p), (bool (*)(const_tree))
+                      helper::fixup_canonical_types);

       tree synth_id = make_generic_type_name ();

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]