This fixes the const bug. I haven't bootstrapped and tested beyond my
own tests yet but this does it. I don't know if this is the right way
to fix this yet, but I think it's pretty close. I'll see if I can make
a better write up tomorrow, but it seems to me that since we never
cared about substituting captures at function template instantiation
time there was never a special case added in here to add the const over
to the var_decl's type. I assume in cases where there is some kind of
type mismatch that it's usually handled before here, but this special
case throws a wrench into the works.

@@ -15402,6 +15450,8 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain,
                  gcc_checking_assert (TYPE_MAIN_VARIANT (TREE_TYPE (ve))
                                       == TYPE_MAIN_VARIANT (type));
                SET_DECL_VALUE_EXPR (r, ve);
+               if (is_capture_proxy (t))
+                 type = TREE_TYPE (ve);
              }
            if (CP_DECL_THREAD_LOCAL_P (r)
                && !processing_template_decl)

Sigh, that was really tough to track down, but it's honestly pretty
relieving that it was MOSTLY using the closure type and not totally
ignoring it. It just misses a step here for some reason, idk if this is
a larger bug that was benign before, or if this case just invalidates
some assumptions, I'm not really sure. I don't really have the energy
to fully understand everything that's going on in here tonight. This
fix is just good enough to bootstrap and run the tests overnight and
hopefully when I check in the morning there won't be any regressions.

Going to get some rest now, as long as the other maybe bugs I found are
not related to xobj parameters we can probably dust off this patch this
week. Although, maybe I should have learned by now that I'm terrible at
estimating timelines.

Alex

Reply via email to