Open jabraham17 opened 1 month ago
The bar
case is a known issue (well, a known-to-me issue, not sure if that makes it "known"...)
When PR #5057 added support for methods on instantiated types with parentheses (as you use above), it didn't handle the implicit this.
part. The reason for this has to do with the production compiler's architecture, where implicit this.
is added before type resolution has been completed.
The proc type getR.baz()
case is similar, in that there is a non-trivial receiver expression. It doesn't use parens, but it's still more complicated than the production compiler's architecture can handle.
AFAIK the Dyno resolver will address both of these when it comes online. So it'd be good to have .futures.
Along those lines, I know of these futures:
test/functions/ferguson/spec-insn-method-no-this.chpl
(for something like the bar
case here)test/classes/ferguson/forwarding/call-forwarded-omit-this.chpl
(for a similar case not described here)Ok, with that in mind I have opened https://github.com/chapel-lang/chapel/pull/26084 to add futures for this case so that these cases don't get forgotten as Dyno comes online.
I expanded test/functions/ferguson/spec-insn-method-no-this.chpl
to handle the baz
case as well and added the similar test/functions/ferguson/spec-insn-type-method-no-this.chplto handle the
type` method cases.
See also issue #5979 which describes some of the cases here (and this issue is arguably a duplicate of that one, but IMO we should keep both because they emphasize different things).
The language spec states that identifiers can be used in a method without an explicit
this.
and still resolve. This is offered without qualification in the spec, and an example is shown with secondary methods. However I have found that secondary methods with more complicated receivers fail to resolve.The following code shows an example of this. In
foo
, implicit this works properly. However bothbar
andbaz
fail to compile sincex
/t
is not considered in scope. Note that in all cases, adding an explicitthis.
causes all functions to resolve properly.I think that in all three functions implicit this should work, and
x
/t
should resolve tothis.x
/this.t
.