This totally works! There's a bug that I'll descri...

# pattern-matching

[mattmoore]

This totally works! There's a bug that I'll describe tomorrow. But I was able to (in addition to running tests) actually run this against a fresh Kotlin project.

[raulraja]

Amazing step fwd!

[shikasd]

Now there's a huge problem that Kotlin is not aware of inferred type of this parameter, as we adding it afterwards. Because of that, it doesn't resolve calls which reference this parameter.

Ideally, it would be great to intercept it during analysis, but I am not sure if we can do it.

@raulraja maybe you have some suggestions?

[raulraja]

we can explicitly bind its psi expression typeReference to a kotlin type based on the constructor position and that should probably get you through analysis

[raulraja]

using the trace and binding context.

[raulraja]

also in the worst case we can intercept the call resolver or provide our own too

[shikasd]

yeah, that's what it is doing right now
the problem is in resolved functions, for example if we do capturedFirstName + capturedSecondName
the + call is not resolved to be related to string, so we basically have to fill a lot of the gaps

[raulraja]

this is probably because those two terms have no associated types resolved in the trace so + isn’t accounted for resolution. Do they show up in the binding trace with a type associated to their KtExpression node?

[raulraja]

At the RHS the compiler may not know yet that those variables refer to the ones on the left declared by destructuring

[raulraja]

If this is pushed already I may be able to take a look

[mattmoore]

Haven't had a chance to check on the + issue, but the latest code is pushed.

[mattmoore]

There's also an issue with putting this into main but hoping to look at that a little later...

[raulraja]

If it helps IR still does not support main without args or suspend main

[raulraja]

It helps to leave main isolated with a single function entry point

[bloder]

Maybe I need to see better the implementation but in this problem of type inference, descriptors cannot help?

[raulraja]

yeah I think the issue is those expressions have no linked descriptor and therefore no type info

[shikasd]

yep, essentially we are linking them afterwards, so that's what happens
Probably we can intercept parts that do type resolution, most likely it will help

[raulraja]

The proof plugin contains a custom call resolver example but uses it standalone so it’s not incercepting it.

[shikasd]

yep, I was a bit braindead yesterday to poke it further, so maybe will take a look today or tomorrow 🙂

[shikasd]

@mattmoore I have managed to make the type resolution working, just needed to hack around the binding context cache and rerun resolution
I have pushed it to my branch for now, but the whole thing is still a bit messy

[mattmoore]

@shikasd Awesome! I’ll take a look today. What’s your branch? 🙂

[shikasd]

It's the one I was merging from last time, pattern-matching in my fork of meta :)