RFR: 8014021: TreeMaker.Params behaves inconsistently when the owning method has the same number of parameters as the number of parameter types requested

[Archie L. Cobbs]

On Sat, 18 Feb 2023 05:06:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> The method `TreeMaker.Params` has what appears to be strange behavior: normally it creates parameters of the types passed in. However, if the given owner is a method, and the method happens to have the same number of parameters as the number of parameters requested, then the types of the owner method's parameters are used instead. This is weird and confusing.
>> 
>> What's really going on is that a method owner is _always_ being passed in, and when that method has parameters defined, there are _always_ exactly as many of them as there are types provided.
>> 
>> So what this method is really doing is just reusing the same symbols for the methods parameters if the method has them defined, otherwise creating the same number of placeholder parameters `x0`, `x1`, `x2`, etc.
>> 
>> This patch refactors this method and clarifies its usage to eliminate the confusion.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeMaker.java line 1071:
> 
>> 1069:      *  otherwse create placeholders x0, x1, ..., xn.
>> 1070:      */
>> 1071:     public List<JCVariableDecl> Params(MethodSymbol mth, List<Type> argtypes) {
> 
> why changing the order of the arguments in the method declaration?

The thought was this: we are adding new preconditions to an existing method. All uses of this method in the JDK itself have been verified to already satisfy these preconditions, but there could (in theory) be other uses outside of the JDK that don't. By changing the method signature, any such uses will no longer compile, instead of silently becoming invalid.

Just trying to be conservative, in other words. But maybe this is too hypothetical, in which case I'm happy to switch it back.

-------------

PR: https://git.openjdk.org/jdk/pull/12627