Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Call resolving for languages without function overloading #1635

Open
peckto opened this issue Jul 25, 2024 · 1 comment · May be fixed by #1860
Open

Call resolving for languages without function overloading #1635

peckto opened this issue Jul 25, 2024 · 1 comment · May be fixed by #1860
Assignees
Labels

Comments

@peckto
Copy link
Collaborator

peckto commented Jul 25, 2024

It might be, that we are a little bit to strict with the current call resolving.
We always check the parameter types, also for languages where no function overloading exists.
This will not map function calls, where one of the parameters have an UNKNOWN type.

This is the relevant code part:

if (call.language !is HasFunctionOverloading) {
// If the function does not allow function overloading, and we have multiple candidate
// symbols, the
// result is "problematic"
if (result.candidateFunctions.size > 1) {
result.success = CallResolutionResult.SuccessKind.PROBLEMATIC
}
}
// Filter functions that match the signature of our call, either directly or with casts;
// those functions are "viable". Take default arguments into account if the language has
// them.
result.signatureResults =

Theoretically, for the "not HasFunctionOverloading" case, we could finish here with an ==1:

if (result.candidateFunctions.size > 1) {
result.success = CallResolutionResult.SuccessKind.PROBLEMATIC
}

Or we only take the shortcut, when one of the types is unknown.
Update: Of course, the number of arguments must match, otherwise something is going wrong.
What do you think?

Example where current call resolving fails:

//#define MY_CONST_INT 1

void foo(int i) {
}

int main() {
    foo(MY_CONST_INT);
    return 0;
}
@peckto
Copy link
Collaborator Author

peckto commented Nov 19, 2024

Independent of the function overloading thing, we could think about, if we want to allow casting from UNKNOWN type to any type to relax and over approximate the function resolution.

@peckto peckto linked a pull request Nov 20, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants