CallSiteValue::get_called_fn_value: return None on indirect calls

[airwoodix]

Description

Fixes #571.

• CallSiteValue::get_called_fn_value now matches the behavior of CallBase::getCalledFunction and returns None when the underlying instruction is an indirect call or a type inconsistency is detected (the latter only for LLVM >= 8).
• The new CallSiteValue::get_called_fn_type corresponds to CallBase::getFunctionType and returns the type of the function called by the underlying call/invoke instruction. This is always well defined, whether the call is indirect or not. This new function only exists for LLVM >=8 because it depends on LLVMGetCalledFunctionType.

Related Issue

#571

How This Has Been Tested

Non-regression on #571 is tested by a dedicated test which uses a simplified version of the issue's reproduction code. For simplicity, this test is restricted to LLVM >= 15 (the test's IR snippet uses opaque pointers).

Doctests of CallSiteValue::get_called_fn_value and the new CallSiteValue::get_called_fn_type cover the usual-case, happy paths.

Breaking Changes

CallSiteValue::get_called_fn_value now returns an Option<FunctionValue> instead of a FunctionValue to model the fact that it may not be possible to retrieve the underlying function value (when the call is indirect).

Discussion

FunctionValue::new differs from most other type constructors (e.g. FunctionType::new) since it checks for the safety requirements and returns None if they are not met:

• is it thus obsolete to have it marked unsafe?
• is it the intention to have most type constructors behave this way, instead of being unsafe?

Checklist

• I have read the Contributing Guide

[TheDan64]

Thanks!

[TheDan64]

is it thus obsolete to have it marked unsafe?

No, I don't think so - a user could still provide an invalid LLVMValue to us I think. So it's still up to the user to validate that value is correct

is it the intention to have most type constructors behave this way, instead of being unsafe?

See above