Account for exact references in indirect call effects

[stevenfontanella]

Part of #8615. Allows us to ignore effects from func subtypes when we have an indirect call to an exact reference.

[tlively]

Something I realized we're probably not handling correctly (but tell me if I'm wrong) is inexact function imports. When I import a function inexactly with type $super, take a reference to it somewhere, and then somewhere else do an indirect call to $sub, it's possible that I end up calling the import. That's because the reference to the imported function reference can be cast to $sub, and that cast might succeed depending on the function that was supplied at instantiation time.

But this is probably a pre-existing bug. I only thought about it because I was considering exactness. It probably makes sense to fix separately.

[stevenfontanella]

Something I realized we're probably not handling correctly (but tell me if I'm wrong) is inexact function imports. When I import a function inexactly with type $super, take a reference to it somewhere, and then somewhere else do an indirect call to $sub, it's possible that I end up calling the import. That's because the reference to the imported function reference can be cast to $sub, and that cast might succeed depending on the function that was supplied at instantiation time.

But this is probably a pre-existing bug. I only thought about it because I was considering exactness. It probably makes sense to fix separately.

I see, even in closed-world mode the import is basically acting as an alias and can redefine the function as a supertype of its real type.

Would something like #8811 be enough to fix it? This PR makes a similar mistake here, so maybe I'd try to fix this more generally before submitting this PR.

[tlively]

Would something like #8811 be enough to fix it? This PR makes a similar mistake here, so maybe I'd try to fix this more generally before submitting this PR.

The type on the Function should already be correct. We just need to make sure we're handling it correctly in the effects analysis.

[stevenfontanella]

I don't understand, there's a TODO for the type field in Function which suggests that it's not correct today, and I also thought that it's not correct based on what you said. If we have

  (import "" "" (func $f (type $super)))

then it looks like the current code will have exact $super as the type for this which I think is wrong.

To fix this PR, I think I'd want to merge #8811 and then use caller->type.getExactness() here instead of Exact. Does that sound correct to you?

[tlively]

I think that TODO is stale. We're already careful to set the exactness correctly in the binary parser and in the text parser.

[tlively]

and then use caller->type.getExactness() here instead of Exact. Does that sound correct to you?

I'm not sure it's sufficient. Normally we flow effects up the subtype hierarchy so that effects in referenced functions of type $f are included in indirect calls to all supertypes of $f. But here if we have a function import of type $f, we need to include the "calls an import" effects in indirect calls to all subtypes of $f as well.