Add missing ids to getExpressionInfo and fix existing bugs

[GulgDev]

This PR adds cases for GC expressions in getExpressionInfo and updates CallIndirectId (fixes #7490), TryId. In addition, it also adds tests for getExpressionInfo results, which were not checked before.

Also, getExpressionInfo is very similar to the expression wrappers, so maybe we should modify this function to just return a copy of the wrapper? If we do so, should we either return the corresponding wrapper or return an object which has all the required properties of the wrapper (should they be value properties or getter properties?)?

[kripken]

Also, getExpressionInfo is very similar to the expression wrappers, so maybe we should modify this function to just return a copy of the wrapper? If we do so, should we either return the corresponding wrapper or return an object which has all the required properties of the wrapper (should they be value properties or getter properties?)?

Yes, that does seem redundant...

Implementing getExpressionInfo using the wrappers might be good. I think we can just return the corresponding wrapper - it's an API change but seems strictly better, and low risk.

[GulgDev]

Implementing getExpressionInfo using the wrappers might be good. I think we can just return the corresponding wrapper - it's an API change but seems strictly better, and low risk.

If we return the wrapper instead of an info object this would not only break some code (they are not strictly equal), but that would also mean that info objects now mutate the state of the expression. Is this change wanted? Maybe it would be better to re-define all properties of the wrapper on a new object, with the needed changes to maintain compatibility with the previous API. Also, should getExpressionInfo be deprecated? Additionally, if the aforementioned function is not required anymore, there should be a way to create a wrapper from an unknown expression id (that is, the end user should be able to construct a wrapper of an expression, the id of which is unknown, just like it was possible with getExpressionInfo).

[kripken]

Yes, being able to get info for an expression of unknown class was probably the main motivation for getExpressionInfo. I agree we can deprecate it if we add such a method that creates a wrapper. Seems safer than a breaking change, good point.

[GulgDev]

Should this be implemented in a separate PR or is it ok to repurpose this one?

[kripken]

Maybe leave that for a later PR? The code in this PR looks good to land, unless it is incomplete somehow?

[GulgDev]

It is complete, but I am working on changing implicit assertInfoEqual to explicit property equality assertions. This would guarantee that any further changes will not break existing API.

[kripken]

Sounds good, let me know when it's ready here.

[GulgDev]

@kripken Done! I've also fixed some bugs that appeared after updating the tests.

[kripken]

Perhaps we could have a UTF8ToStringOrNull helper for this pattern, but we can consider that separately.