feat(useExplicitType): support explicit function argument types

[kaykdm]

Summary

related: #2017

This PR adds support for enforcing explicit type annotations on arguments in all functions and class methods. The rule is inspired by the explicit-module-boundary-types rule, but it expands coverage beyond exported functions to include all functions and methods within a class.

[codspeed-hq]

CodSpeed Performance Report

Merging #4647 will not alter performance

_{Comparing kaykdm:feature/explicit-argument-types (98064bc) with main (cd1c8ec)}

Summary

✅ 97 untouched benchmarks

[kaykdm]

to continue the discussion from this

Usually we try to avoid allocating a string. You could directly take the token:

@Conaclos

Thank you for the feedback! I decided to keep the same implementation for the following reasons:

• Even if we use the token directly instead of passing a String, we still need to call the to_string() method to pass the value to markup! {}, which will allocate a string regardless. So, both approaches result in string allocation.
• Additionally, in cases like function foo({a: b}), we need to handle tokens differently. For instance, the first token in this scenario would be '{'.

[kaykdm]

to continue the discussion from this

I wonder if directly matching against JsParameters is a good idea. I see two possible alternative approaches:

• matching directly against JsFormalParameter, JsRestParameter, and TsThisParameter
• matching against functions with parameters (We already have most of them, we need to add setter and constructors).

@Conaclos
Thank you for the suggestion! I decided to implement matching directly against JsFormalParameter, JsRestParameter, and TsThisParameter because it keeps the code simpler and more straightforward.

[Conaclos]

The issue with (1) is that you have to check again if the argument can be untyped (That corresponds to the same heuristics that allows untyped return type). I noticed you didn't implemnt these exceptions.

For insatnce, teh following code should be accepted:

const f: MyFunction = (a) => a;

Also, creating a diagnostic for every argument / return type seems noisy?

[ematipico]

@kaykdm just checking in if this PR still needs a review or not?

[kaykdm]

@kaykdm just checking in if this PR still needs a review or not?

@ematipico @Conaclos
Sorry for the late response. I still need to work on this PR, but I haven't had much time lately. I'll close this PR for now. Thank you for checking in!