fix(jsii-pacmak): underscore arguments conflict in Java (#5011)

The `_` identifier is treated as a keyword since Java 9, and we used to escape it to `__`.

The problem is that but it is somewhat likely that people will use `_, __, ___` as multiple indifferent arguments, and now the identifiers will conflict. We have to pick something else.

Ideally we would look at the surrounding argument names and pick something guaranteed to be unique, but unfortunately the code isn't quite structured that way so we'll pick something unlikely to collide instead. We escape it to `_under_` instead.

Changing from `__` -> `_under_` would be a breaking change if applied to public property names, but most likely this will be used for function parameters (unfortunately the code has been structured in such a way that property and parameter names are strongly tied together, in a way that would take more time to unwind than I care to invest right now), where it doesn't matter.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the [Apache 2.0 license].

[Apache 2.0 license]: https://www.apache.org/licenses/LICENSE-2.0

Author: rix0rrr

packages/jsii-calc/lib/module2530/index.ts

@@ -14,4 +14,8 @@ export class MyClass {
   public foo(_: string) {
     return;
   }
+
+  public multipleUnderscores(_: string, __: string, ___: string) {
+    return;
+  }
 }

packages/jsii-calc/test/assembly.jsii

@@ -17960,6 +17960,36 @@
               }
             }
           ]
+        },
+        {
+          "docs": {
+            "stability": "stable"
+          },
+          "locationInModule": {
+            "filename": "lib/module2530/index.ts",
+            "line": 18
+          },
+          "name": "multipleUnderscores",
+          "parameters": [
+            {
+              "name": "_",
+              "type": {
+                "primitive": "string"
+              }
+            },
+            {
+              "name": "__",
+              "type": {
+                "primitive": "string"
+              }
+            },
+            {
+              "name": "___",
+              "type": {
+                "primitive": "string"
+              }
+            }
+          ]
         }
       ],
       "name": "MyClass",
@@ -19960,5 +19990,5 @@
     "intersection-types"
   ],
   "version": "3.20.120",
-  "fingerprint": "vOdExLwYXggdf/TTFym/I+wkv5Ih6GlEJke+UiAjaXo="
+  "fingerprint": "lIHvj1O/NYsjHa9x/fPvrEdD8ChVE2BSlsfyzXUQaP4="
 }

packages/jsii-pacmak/lib/targets/dotnet/nameutils.ts

@@ -85,6 +85,16 @@ export class DotNetNameUtils {
       throw new Error(`Invalid parameter name: ${original}`);
     }
     const name = toCamelCase(original);
+    if (!name) {
+      // toCamelCase will return an empty string from a string like `_(_+)`. Confirm that
+      // that is what is happening, then return the original string.
+      if (original.match(/^__+$/)) {
+        return original;
+      }
+      throw new Error(
+        `toCamelCase returns an empty string from: ${JSON.stringify(original)}`,
+      );
+    }
     return this.escapeParameterName(name);
   }
 

packages/jsii-pacmak/lib/targets/java.ts

@@ -608,8 +608,22 @@ class JavaGenerator extends Generator {
     }
 
     if (propertyName === '_') {
-      // Slightly different pattern for this one
-      return '__';
+      // Slightly different pattern for this one. We used to generate `__` here
+      // but it's somewhat likely that people will use `_, __, ___` as multiple
+      // indifferent arguments, so we pick a different name.
+      //
+      // Ideally we would look at the alternative argument names and pick
+      // something guaranteed to be unique, but unfortunately the code isn't
+      // quite structured that way so we'll pick something unlikely to collide
+      // instead.
+      //
+      // Changing from `__` -> `_under` would be a breaking change if applied to
+      // public property names, but most likely this will be used for function
+      // parameters (unfortunately the code has been structured in such a way
+      // that property and parameter names are strongly tied together, in a way
+      // that would take more time to unwind than I care to invest right now),
+      // where it doesn't matter.
+      return '_under_';
     }
 
     if (JavaGenerator.RESERVED_KEYWORDS.includes(propertyName)) {