dyno: Support non-local receivers and improve resolution of type queries

[dlongnecke-cray]

This PR adds support for non-local receivers to dyno and fixes a bug affecting the resolution of type queries. It adds support for programs like the following:

    class Foo {
      type T;
      proc get(type t) type do return t;

      proc foo() {
        // Here 'nested' is not a method, but 'this' is still visible as
        // an outer variable. It is a non-local receiver from the
        // parent method 'foo'.
        proc nested(x : get(T)) do return x;
        return nested(0);
      }
    }

Refactor the Resolver::methodReceiverType() method to make use of a new method closestMethodReceiverInfo(). Remove getMethodReceiver and streamline how receiver information is computed. When resolving, try to compute a local method receiver using whatever means are available. If that fails, consult stack frames for the first method that lexically encloses the current symbol and use its receiver instead.

In getMethodReceiverScopeHelper() and friend, flatten out the branches used to make the function idempotent and to handle scopeResolveOnly. This makes the typed path for setting up the helper easier to digest.

Fix a bug in type query resolution that caused every call to be treated as though it were a type constructor for a composite type. To do this, compute if type queries are present in children in Resolver::resolveTypeQueries and do nothing if they are not. Secondly, rely on the Resolver::signatureOnly flag to avoid emitting errors unless we are resolving a signature and have access to the types of sub-expressions.

Reviewed by @mppf. Thanks!

[mppf]

My only concern is that, perhaps, we can get the resolver to work more with ReceiverScopeTypedHelper / TypedMethodLookupHelper. The scope resolution process works with these so that it doesn't even need to think about the "closest" method receiver. That should not be relevant to the process.

That said, I think this PR has some good cleanups and gets some more cases working, so we can proceed with it.

[mppf]

We can consider making this a full-on error for now. Would that break tests in production?

[mppf]

fwiw, I wouldn't use the term "barrier" here since it means something specific (and different) in parallel computing. IMO the comment could just be "only compute the receiver scopes once".

[mppf]

ditto

[dlongnecke-cray]

Do you mean that maybe we can have those types themselves compute the closest method receiver? I think something will have to walk the stack in some way at some point to get at the types, but I'm not picky about what does it.

[mppf]

Do you mean that maybe we can have those types themselves compute the closest method receiver? I think something will have to walk the stack in some way at some point to get at the types, but I'm not picky about what does it.

It's more that even the idea of whether or not the "closest method receiver" is relevant (vs all method receivers) should be up to the scope lookup code (according to LOOKUP_INNERMOST). For example, we might have nested methods (where the inner method is a secondary/tertiary method) and then things like x and y could refer to either object. So I think it would be more consistent to always let the LookupHelper code decide when to stop going up the stack, so to speak.