Print deprecation warnings on deprecated method argument#15999
Conversation
At this point, the target def args and the call args are matching, and we don't have to match the args, named args, splats and double splats.
|
Glad to see another solid use case for annotations on parameters! Good stuff! |
straight-shoota
left a comment
There was a problem hiding this comment.
Sorry for the pedantic nagging: I'd prefer to extract some of the changes into separate PRs. Especially the first two commits with bugfixes should be merged individually.
I suppose the rest can be together as part of this feature.
|
Hum, I should add specs for |
|
Of course, the |
|
Now with fix from #16013 and specs for expansion of |
…n-deprecated-method-argument
|
I fixed the conflicts with |
We can annotate a method argument, which means we can technically put the
@[Deprecated]annotation to deprecate a method argument, but there was no incentive to do it... yet.In #15924 we want to deprecate a specific method argument (
blocking) and we can't use the usual duplicated methods, one with the argument (deprecated) and another one without it, because it too many cases this is a positional argument, and it comes after other positional arguments with a default value.This PR adds deprecation checks for method arguments, and prints a warning when an argument is deprecated. For example:
Will generate the following deprecations, only complaining when we pass an explicit value to the deprecated argument (the first two calls are fine, the last two are not):
See the specs for all the different cases, inclusing splats, and double splats.
The PR also fixes a couple pre-requisites, for example making sure that each arg annotation is correctly copied when expanding or duplicating a def, or that the original name of an arg is also carried over, so we don't complain about
argument __temp_1being deprecated.