This is really a reference

[llvm-beanz]

This fixes a few cases that were missed when I updated this objects to be references. Specifically we were still generating some implicit this cases as pointers, and we were not always correctly looking through the reference types.

Fixes #4709

[pow2clk]

Looks good though I'd still like the comments in the tests.

I'd like to have a discussion about the nonsensical LValueToRvalue casts. I've heard you mention it before and I'd like to understand why they exist and what to do about them.

[pow2clk]

I would appreciate a comment at the top of both of these tests explaining briefly what's being tested

[llvm-beanz]

I'd like to have a discussion about the nonsensical LValueToRvalue casts. I've heard you mention it before and I'd like to understand why they exist and what to do about them.

Here's a simple example of the kinds of nonsense casts we get in the AST. Take this code:

struct Doggo {
  int4 Legs;
};

void Walk(inout Doggo D);

void fn() {
  Doggo D = {1.xxxx};
  Walk(D);
}

Godbolt Link.

When D is passed to Walk, it is an l-value. It gets modified by Walk so it must be an l-value. But the AST is this:

CallExpr <line:10:3, col:9> 'void'
|-ImplicitCastExpr <col:3> 'void (*)(__restrict Doggo)' <FunctionToPointerDecay>
| `-DeclRefExpr <col:3> 'void (__restrict Doggo)' lvalue Function 'Walk' 'void (__restrict Doggo)'
`-ImplicitCastExpr <col:8> 'Doggo' <LValueToRValue>
  `-DeclRefExpr <col:8> 'Doggo' lvalue Var 'D' 'Doggo'

According to the AST, D gets l-value to r-value casted and the r-value of D gets passed into the AST. In this case it is because the AST doesn't represent UDTs being passed inout.

There are other cases where we do this wrong too. Fixing the ASTs to be accurate is the intent of #5249.