SONARPY-525 Rule S5655: Arguments given to functions should be of an expected type#672
SONARPY-525 Rule S5655: Arguments given to functions should be of an expected type#672guillaume-dequenne merged 3 commits intomasterfrom
Conversation
d08f9b6 to
365c7f1
Compare
There was a problem hiding this comment.
I have the feeling we shouldn't have this logic happening in FunctionSymbol.
Having an implicit parameter doesn't depend on how the function is defined, but instead on how /where the function is called.
The information we may miss today in FunctionSymbol interface is the names of the decorators
There was a problem hiding this comment.
I have removed that API and added a new one to retrieve decorators in d9e48824b4d75f149e2db5cfcac09b46ad1a8fe9.
There was a problem hiding this comment.
I think I would prefer having a method setParametersDeclaredType(ParameterList parameterList) instead of having separate methods to clear and add
There was a problem hiding this comment.
Indeed! I refactored that part in d9e48824b4d75f149e2db5cfcac09b46ad1a8fe9.
There was a problem hiding this comment.
You can access it via FunctionDefImpl.functionSymbol()
There was a problem hiding this comment.
I don't like this name, what about canBeOrExtend(InferredType other)?
There was a problem hiding this comment.
Why can't we do it inside FunctionSymbolImpl constructor anymore?
There was a problem hiding this comment.
I tried adding that logic again in FunctionSymbolImpl constructor but encountered a different issue where some class symbols could have their super class read through type annotations before their type hierarchy was defined.
Therefore, in d9e48824b4d75f149e2db5cfcac09b46ad1a8fe9, I moved this logic to ThirdPhaseVisitor.
e58162a to
d9e4882
Compare
There was a problem hiding this comment.
why declaredType is Nullable?
There was a problem hiding this comment.
I forgot to remove that...Fixed it in 6a53bddec8101c389dc573bcbf56eb2f79c5a585
There was a problem hiding this comment.
I think functionSymbol.is(Symbol.Kind.FUNCTION) shouldn't be necessary
There was a problem hiding this comment.
I don't understand why if otherFullyQualifiedName is null we call typeClass.hasUnresolvedTypeHierarchy()? Probably it's better to return true
There was a problem hiding this comment.
Indeed, also this case should normally never happen.
I fixed this in 6a53bddec8101c389dc573bcbf56eb2f79c5a585.
Please note that b275a488d001987df20f088dc8a1711c6ffe47fe also introduce changes to this method to account for duck type compatibility.
There was a problem hiding this comment.
I think it would be nice to have a test with a null fully qualified name
There was a problem hiding this comment.
Maybe we can add a comment to explain why we ignore this case
There was a problem hiding this comment.
I think we should have a test for functions defined with variadic parameters (*args and **kwargs)
There was a problem hiding this comment.
Indeed! Actually that made me realize we don't handle them very well as we only rely on type annotation without knowing whether the parameter is variadic or not. In 6a53bddec8101c389dc573bcbf56eb2f79c5a585 I have therefore disabled the rule when a function has variadic parameters.
fe6de77 to
c31e73a
Compare
andrea-guarino-sonarsource
left a comment
There was a problem hiding this comment.
LGTM, as discussed before merging please split commits adding API from the rule implementation.
c31e73a to
de41af4
Compare
de41af4 to
67f6fb3
Compare
|
Kudos, SonarQube Quality Gate passed! |
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> GitOrigin-RevId: 7a013b5b756bfc434de92ca7736265ca81de62ec
No description provided.