I guess I'll be attaching all new e-mails here.
I found a new, kinda scary issue.
```
bool
start_preparsed_function (tree decl1, tree attrs, int flags)
{
tree ctype = NULL_TREE;
bool doing_friend = false;
/* Sanity check. */
gcc_assert (VOID_TYPE_P (TREE_VALUE (void_list_node)));
gcc_assert (TREE_CHAIN (void_list_node) == NULL_TREE);
tree fntype = TREE_TYPE (decl1);
if (TREE_CODE (fntype) == METHOD_TYPE)
ctype = TYPE_METHOD_BASETYPE (fntype);
else if (DECL_XOBJ_MEMBER_FUNC_P (decl1))
ctype = DECL_CONTEXT (decl1);
```
```
if (ctype && !doing_friend && !DECL_STATIC_FUNCTION_P (decl1))
{
/* We know that this was set up by `grokclassfn'. We do not
wait until `store_parm_decls', since evil parse errors may
never get us to that point. Here we keep the consistency
between `current_class_type' and `current_class_ptr'. */
tree t = DECL_ARGUMENTS (decl1);
gcc_assert (t != NULL_TREE && TREE_CODE (t) == PARM_DECL);
gcc_assert (TYPE_PTR_P (TREE_TYPE (t))
|| DECL_XOBJ_MEMBER_FUNC_P (decl1));
cp_function_chain->x_current_class_ref
= cp_build_fold_indirect_ref (t);
/* Set this second to avoid shortcut in cp_build_indirect_ref. */
cp_function_chain->x_current_class_ptr = t;
/* Constructors and destructors need to know whether they're "in
charge" of initializing virtual base classes. */
/* SNIP IRRELEVANT */
}
```
I made changes in this function, which suddenly sent execution into the
second code block. It seems like this would have been being bypassed
until the fix at the top of the function. Initially this was to fix a
problem with lambdas, but suddenly a lot of other stuff seems to be
breaking. I haven't run the tests yet but... I have a really bad
feeling about this.
So my concerns here are, one, this seems kind of important upon looking
at it, what kind of stuff might have been broken when this was being
bypassed that I didn't notice? And two, how in the world was it working
when this was being bypassed?
I have a hunch that some of the reinterpretation and "just works"
behavior might have had something to do with this block of code being
bypassed. I also suspect that this area will need some changes to make
by-value xobj parameters work. However, I'm a little confused at why
this block is necessary at all. Like I have noted before, when
attempting to call a by-value xobj member function, if there are no
viable conversions, the call will fail. So it's checking for that
somewhere.
normal.C: In explicit object member function 'uintptr_t S::f(this uintptr_t)':
normal.C:15:33: error: invalid type argument (have 'uintptr_t' {aka 'long
unsigned int'})
15 | uintptr_t f(this uintptr_t n) {
| ^
normal.C: In explicit object member function 'uintptr_t S::g(this FromS)':
normal.C:18:34: error: invalid type argument (have 'FromS')
18 | uintptr_t g(this FromS from_s) {
| ^
But now that we are entering this code block, (when compiling
explicit-obj-by-value2.C) these errors are popping up. Why now? Why
isn't this being handled in the same place other things are? How
important is this block of code really? Is this the origin of the weird
errors where rvalue refs are being accepted for functions that take
const rvalue refs?
Is this code just setting up the 'this' pointer? I have so many guesses
and so many questions. I don't think I can just bypass it though, but
maybe I can? This is another one that feels really deep down the rabbit
hole so I would appreciate any insight that can be provided.
Anyway, I had thought that I probably just need to change how
build_over_call works to get passing to by-value xobj params to work.
But now that I've found this code and gotten these new errors to
surprise me, now I'm a little worried.
If it's just for the 'this' pointer then it's probably fine. I need to
sleep now, I hadn't planned on looking at this for as long as I did but
I got sucked in. I think tomorrow I will go back to bypassing this code
block and try to make changes to build_over_call works and see if that
does the trick. But things feel all over the place now so I'm a little
concerned about what else I might be neglecting.
Thanks,
Alex
