Fix C style function resolution #1860
Conversation
…e information is missing
| if (result.candidateFunctions.size > 1) { | ||
| result.success = CallResolutionResult.SuccessKind.PROBLEMATIC | ||
| } else | ||
| // If we have only one candidate function and the number of arguments match, we can take |
There was a problem hiding this comment.
This has multiple issues
- This does not only affect C but other languages as well.
- It does not take into account if languages have default arguments
At the very least I think we need to make this configurable. Depending on the use case you MAY or MAY NOT want to do this. For example if you actually want to check if something is resolving similar to a compiler (e.g., also inference turned off), you want to have an empty list of invokes edges here.
If you want to be very optimistic about matching types, this may be another (maybe even global?) configuration option. You can always of course override the tryCast in a language that depends on the C language if you want to have a "matches-everything-C-language`.
So I am very skeptical about this change.
There was a problem hiding this comment.
Yes, that's true, default arguments are a problem, haven't thought about that.
Also the go var args arguments fail.
Do we have a language feature for that to match on?
Affecting other languages is not a problem per se I would say, but other languages bring other combinations of features, which must be taken into account during the resolution.
Override the tryCast might be an alternative for the C language.
Not sure if we want to make this configurable, as long as it is conform with the language design.
Configuration options tend to be only used by the person who implemented them and others are wondering why it's not working, not knowing about the option.
Do not use signature based symbol resolving for languages without function overloading.
Fixes: #1635