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