dylanhz opened a new pull request, #27787:
URL: https://github.com/apache/flink/pull/27787

   ## What is the purpose of the change
   
   Fix a bug where UDF type inference throws "Argument name conflict" when a 
method (e.g. eval, accumulate) contains a lambda expression that captures its 
own parameters.
   
   The ASM-based `ParameterExtractor` in `ExtractionUtils` matched target 
methods only by bytecode descriptor, ignoring the method name. When a lambda 
captures parameters of the enclosing `eval` method, the Java compiler generates 
a `lambda$eval$N` synthetic static method with the same descriptor. The 
`ParameterExtractor` visits both the real `eval` and the synthetic method, 
causing the lambda's local variable names (starting at slot 0) to overwrite the 
instance method's parameter entries (where slot 0 is `this`) in the shared 
`TreeMap`, producing duplicate names and triggering the validation error.
   
   ## Brief change log
   
     - Store `methodName` in `ParameterExtractor` (`method.getName()` for 
methods, `"<init>"` for constructors)
     - Match on both `name.equals(methodName) && 
descriptor.equals(methodDescriptor)` in `visitMethod` to avoid visiting lambda 
synthetic methods
   
   ## Verifying this change
   
   This change added tests and can be verified as follows:
   
     - Added a unit test in `ExtractionUtilsTest` that directly verifies 
`extractExecutableNames` returns correct parameter names for a method 
containing a lambda that captures its own parameters
     - Added an integration test in `TypeInferenceExtractorTest` that verifies 
end-to-end type inference succeeds for a `ScalarFunction` with lambda capture
   
   ## Does this pull request potentially affect one of the following parts:
   
     - Dependencies (does it add or upgrade a dependency): no
     - The public API, i.e., is any changed class annotated with 
`@Public(Evolving)`: no
     - The serializers: no
     - The runtime per-record code paths (performance sensitive): no
     - Anything that affects deployment or recovery: JobManager (and its 
components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
     - The S3 file system connector: no
   
   ## Documentation
   
     - Does this pull request introduce a new feature? no
     - If yes, how is the feature documented? not applicable


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to