A software patch enhancement method and system fusing static program analysis and large language model type inference

Abstract

The application discloses a software patch enhancement method and system fusing static program analysis and large language model type inference. In the application, the system comprises an input interface, a patch analysis module, a warehouse-level code analysis module, a context distillation module, a hybrid type inference module, a patch rewriting module and a verification output module. The input interface receives candidate patches generated by an original software engineering intelligent agent, a target code warehouse and problem description and test information; through patch integrity checking, warehouse-level AST and control flow analysis, definition calculation, static analysis and large model joint type inference, evidence-based type suggestions are formed; then the candidate patches are rewritten according to the evidence-based type suggestions and multi-layer verification is performed, so that the repair success rate of type-related problems is improved, and the expected functions and standard patch formats of original problems are maintained.

Description

Technical Field

[0001] This invention belongs to the field of software engineering technology, specifically a software patching enhancement method and system that integrates static program analysis and large language model type inference. Background Technology

[0002] With the rapid development of large language models, software engineering agents based on large language models have become an important research direction in the field of automated program repair. Early research showed that general-purpose large language models such as GPT-3 and Codex can generate reasonable patches without special fine-tuning for automated program repair. Building on this, researchers have further developed various agent-based automated program repair schemes. For example, RepairAgent is the first to address program repair challenges using an autonomous agent based on a large language model, while ChatRepair combines conversational patch generation with real-time feedback for automated program repair. In terms of evaluation, benchmark tests such as SWE-bench require agents to have efficient patch generation and verification capabilities, driving the rapid development of this field. Currently, the mainstream approach for generating patches using software engineering agents based on large language models is as follows: the agent automatically locates the defective code and generates candidate patches with a unified difference format based on the defect description, code repository context, and test feedback. Representative schemes include AutoCodeRover, Agentless, Moatless Tools, Aider, AppMap Naive, and SWE-Agent. These solutions employ mechanisms such as abstract syntax tree analysis, fault location, repository code mapping, phased reasoning, or agent-computer interfaces, and have made progress in some repair tasks. Besides agents directly generating patches, existing technologies also include traditional static type checking methods and patch review or rewriting methods based on large language models.

[0003] However, existing technologies have the following drawbacks:

[0004] 1. Strong locality: The patch generation phase focuses on the modification points, making it difficult to obtain the complete type relationships of variables across functions, modules, and multiple execution paths.

[0005] 2. Dynamic types are difficult to determine: Type information may be implicit or distributed across multiple files, and simple syntax checking cannot identify complex containers and user-defined types.

[0006] 3. Lack of evidence constraints: Large models may guess the type based on variable names or common patterns, resulting in patches that seem reasonable but are inconsistent with the actual use of the repository.

[0007] 4. Insufficient patch integrity: Incorrect uniformity of header, file path, block marker, or code syntax can cause patches to fail directly during the application phase.

[0008] 5. Insufficient framework integration: Patches may bypass existing configurations, utility functions, and design patterns, resulting in hard-coded, repetitive logic, or inconsistent behavior.

[0009] 6. Incomplete verification chain: Running only a small number of tests cannot simultaneously guarantee the consistency of patch format, syntax, and type. Summary of the Invention

[0010] The purpose of this invention is to provide a software patching enhancement method and system that integrates static program analysis and large language model type inference in order to solve the problems mentioned above.

[0011] The technical solution adopted in this invention is as follows: A software patching enhancement method integrating static program analysis and large language model type inference, characterized by comprising the following steps:

[0012] S1: Receives candidate unified difference patches P, target code repository R, ​​problem description I, and optional tests T; parses the target files, modified blocks, added lines, and deleted lines in P to form a set of modified files F, a set of modified functions M, and a set of variables to be analyzed V. Candidate patches are generated by any auto-repair agent and their internal structure is not required to be changed.

[0013] S2: Perform multi-level uniform difference format validation, checking diff --git, ---, +++, file paths, and @@ modification block markers; stop if the format does not meet the requirements. Extract newly added code lines and restore them to parsable segments, then construct the AST using a parser; if there are syntax errors, record them and prevent further analysis.

[0014] S3: Parse the repository source files to construct an AST, and retrieve variable definitions, assignments, etc. around V. Construct a CFG for the affected functions and perform definition reach analysis: calculate IN, GEN, KILL, and OUT, iterate to a fixed point, and obtain the possible definition sources and type changes of the variables.

[0015] S4: Retain type-related information from the analysis results, including assignments, function signatures, return statements, method calls, property accesses, container operations, configuration items, etc., and compress them into variable-level context packages to reduce the length of LLM inputs and maintain traceability of evidence.

[0016] S5: Static inference provides candidate types for literals, containers, expressions, etc.; when uncertain, it provides candidate types, evidence fragments, and context to the LLM for semantic refinement; it outputs variable identifiers, candidate types, confidence and supporting evidence, and provides rewrite suggestions for nullable, union, nested, etc.

[0017] S6: Input the original patch, problem description, context and type suggestions into the rewrite model, keep the format, make only necessary modifications, prioritize the reuse of existing tools and patterns, and add type checks, conversions, nullable handling, etc.

[0018] S7: Revalidate the format and path, parse the AST again, call mypy to check the type, apply patches to the isolated environment and run the test; if successful, output the refined patch, evidence and logs; if unsuccessful, output the diagnosis; set security permissions.

[0019] In a preferred embodiment, in step S1, the system receives candidate unified difference patches, the target code repository to be patched, the corresponding software problem description, and optional failure test information generated by any software engineering agent or automatic repair tool. The system parses the target file paths, the location and scope of the modified blocks, newly added code lines starting with a plus sign, and deleted code lines starting with a minus sign from the candidate patches, and accordingly forms the set of modified files involved in this patch, the set of affected functions, and the set of variables that need to be analyzed in detail.

[0020] In a preferred embodiment, in step S2, a multi-layered unified difference format check is first performed on the candidate patch. This checks whether the patch header contains a `diff --git` flag, the old file path represented by three minus signs, the new file path represented by three plus signs, and a modification block start flag containing the starting line number and context line number. If the format check fails, the system outputs the specific error location and terminates the subsequent type analysis process. Simultaneously, it may return format error information to the original agent to request patch regeneration. If the format check passes, the system extracts new code lines starting with a plus sign from each modification block that are not part of the file header. These code lines are then restored according to their respective functions or code blocks to form independently parsable code fragments. An abstract syntax tree is then constructed using a parser for the corresponding programming language. If a syntax error is found during parsing, the error type, line number, and code content are recorded to prevent invalid patches from entering the subsequent repository-level analysis stage.

[0021] In a preferred embodiment, in step S3, the system parses all source files in the target code repository and constructs a complete abstract syntax tree. Around the set of variables to be analyzed determined in step S1, the system retrieves the definition location, assignment operation, function parameter passing, return value type, container construct expression, method call, and cross-file usage location of each variable within the syntax tree. For functions affected by the patch, the system constructs a control flow graph, where nodes correspond to statements or basic blocks, and edges correspond to possible execution path transitions. Based on this, the system performs reach-definition analysis, calculating the valid definition set at the entry point and the valid definition set at the exit point for each node in the control flow graph.

[0022] For any node n in the control flow graph, the system denotes pred(n) as the set of all predecessor nodes, i.e., there exist directed edges pointing to all nodes n. INn represents the set of valid definitions at the entrance of node n, OUTp represents the set of valid definitions at the exit of any predecessor node p, and the set of valid definitions at the entrance of node n is equal to the union of the sets of valid definitions at the exits of all predecessor nodes. GENn represents the set of definitions generated by node n itself, KILLn represents the set of definitions that node n eliminates, and the set of valid definitions at the exit of node n is equal to the union of the remaining parts of GENn and INn after removing KILLn. The above relationships are expressed mathematically as follows:

[0023] INn=⋃p∈pred(n)OUTp

[0024] OUTn=GENn∪INn\KILLn

[0025] The system iteratively updates the entry and exit sets of all nodes according to the two formulas mentioned above. The OUT set calculated in the current iteration is used as the input for the next iteration. This process is repeated until the IN and OUT sets of all nodes no longer change, at which point the data flow analysis reaches a fixed point. Through this analysis, the system can obtain information about the possible definitions of variables at each program point and the type information carried by these definitions.

[0026] In a preferred embodiment, in step S4, the system filters out information entries directly related to type determination from the large number of intermediate results generated by the repository-level static analysis. This information includes variable assignment expressions, parameter and return value type annotations in function signatures, expressions in function return statements, receivers and parameter types of method calls, target object types for attribute access, read and write operations on container elements, and usage patterns of the same variable in other modules. The system compresses this information, removing duplicate content and code snippets unrelated to patch modifications, forming a variable-centric context package. This context package preserves the traceability of evidence sources and controls the length of subsequent large language model inputs to avoid exceeding the context window limit.

[0027] In a preferred embodiment, during step S5, literal expressions are directly assigned their corresponding basic types during static type inference. Container creation operations such as list construction and dictionary construction infer their container types. For general expressions, function call return values, and variables on the definition propagation chain, the system performs forward propagation of candidate types on the control flow graph. When static analysis cannot determine the internal element types of complex nested containers, the specific types of user-defined classes, or the semantic types of specific domains, the system submits the variable-level context package formed in step S4, the candidate type list inferred in the static phase, and the corresponding abstract syntax tree and control flow graph evidence fragments to the large language model. The large language model combines this evidence to perform semantic-level type refinement. The final output information includes the variable's canonical identifier, the specific file and function where the variable resides, the program point location, one or more candidate types and their confidence ranking, and a traceable chain of evidence supporting the type conclusion. Simultaneously, specific type rewriting hints are provided for nullable types, union types, nested container types, and user-defined types.

[0028] In a preferred embodiment, in step S6, the system inputs the original candidate patch, the software problem description text, the context fragment of the code modified by the patch, and the structured type suggestions output in step S5 into the patch rewriting model. When generating a refined patch, the rewriting model is required to fully retain all file header information, modification block start markers, and line prefix symbols from the original candidate patch, while limiting the scope of modification to the code areas necessary for problem fixing. Regarding type handling, the rewriting model supplements type checking logic, explicit type conversion operations, null value handling for nullable variables, and correct operation methods for complex data structures at appropriate locations based on the structured type suggestions. During the rewriting process, existing utility functions, configuration parameters, and existing design patterns in the codebase are reused preferentially to avoid introducing duplicate logic or implementations inconsistent with the codebase style.

[0029] In a preferred embodiment, in step S7, the system first performs a unified difference format verification on the rewritten refinement patch again, including integrity checks on file paths and modification block markers, to ensure that the patch can be applied normally by standard version control tools. The system then re-executes abstract syntax tree parsing on the newly added or modified lines of code in the refinement patch to confirm syntactic correctness, and then calls a static type checker to perform consistency checks on type annotations and type operations of the relevant code. After the above verifications pass, the system applies the refinement patch in an isolated sandbox environment and runs the target project's test suite. If all tests pass, the system outputs the refinement patch, evidence records of type inference, and a complete verification log. If the tests fail, the system outputs diagnostic information containing the reasons for the failure for use by the original agent or to proceed to subsequent rewrite iterations. Throughout the verification process, access to the code repository, application of the patch, and test execution are all completed in an isolated environment. The system sets minimum permissions for network access and sensitive file operations and retains complete audit logs.

[0030] In a preferred embodiment, a software patching enhancement system that integrates static program analysis and large language model type inference includes the following modules:

[0031] The input interface module is used to receive candidate patches, target code repositories, problem descriptions and test information generated by the original software engineering intelligent agent, and to standardize the received data.

[0032] The patch analysis module is used to parse the target file path, modified block position, added code line and deleted code line in the candidate patch to form a set of modified files and a set of variables to be analyzed. It performs uniform difference format verification on the candidate patch, checks the file header path identifier and modified block start mark, performs abstract syntax tree parsing on the added code line to check the syntax correctness, and outputs the error position and terminates the subsequent process when the verification fails.

[0033] The repository-level code analysis module is used to parse source files in the target code repository and build a complete abstract syntax tree. It retrieves the definitions, assignments, function parameters, return values, method calls, and cross-file usage locations of variables around the set of variables to be analyzed. It constructs a control flow graph for functions affected by patches and performs reach-definition analysis. It iteratively calculates the set of valid definitions at the entry and exit points of each node until a fixed point is reached.

[0034] The context distillation module is used to extract assignment expressions, function signatures, return statements, method calls, property accesses, container operations, and cross-module usage patterns directly related to type determination from repository-level analysis results. It compresses the extracted information, removes duplicates and irrelevant content, forms a variable-level type context package, and preserves the traceability of the evidence source.

[0035] The hybrid type inference module is used to initiate the static type inference process, assign basic types to literals, infer container types from container constructs, perform forward propagation of candidate types for expressions and return values, and submit variable-level context packages and candidate type lists to the large language model for semantic refinement when static analysis cannot determine complex nested structures or user-defined types. The output includes structured type suggestions containing variable identifiers, candidate types and confidence scores, and supporting evidence chains.

[0036] The patch rewrite module is used to input the original candidate patches, problem descriptions, code context, and structured type suggestions into the patch rewrite model, keeping the file header, modification block markers, and line prefixes unchanged. Within the scope necessary for repair, it adds type checking, type conversion, null value handling, and data structure operations, prioritizes the reuse of existing tools and design patterns in the codebase, and outputs refined patches.

[0037] The verification output module is used to perform uniform difference format verification, abstract syntax tree parsing verification, and static type consistency verification on the refined patch. It applies the patch in an isolated sandbox and runs the target project test. When the test passes, it outputs the refined patch and verification record. When it fails, it outputs diagnostic information and sets minimum permissions and audit records for network access and sensitive file operations.

[0038] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0039] 1. In this invention, various candidate patches are integrated without altering the original software engineering intelligent agent's internal generation process. Before the patches enter in-depth analysis, strict format validation and syntax checks are performed to intercept candidate patches that do not conform to the unified difference format standard or contain syntax errors, effectively avoiding the waste of subsequent computing resources on unapplicable patches. Simultaneously, the abstract syntax tree parsing of the complete code repository provides a definite and traceable evidentiary basis for type inference, effectively improving the accuracy and reliability of type inference.

[0040] 2. In this invention, the determinism of static analysis is organically integrated with the semantic understanding capability of a large language model. Static type inference can provide accurate type conclusions for literals, container constructions, and simple expressions, while the large language model refines the judgment for complex nested structures, user-defined types, and framework-specific domain semantics. This reduces the type misjudgment and format corruption problems that are prone to occur when the large model works alone. It not only ensures the traceability of evidence but also effectively reduces the input length and computational cost of the large language model, significantly improves the applicability of patches and the pass rate of tests, and effectively reduces the risk of patch failure due to improper type handling. Attached Figure Description

[0041] Figure 1 This is a flowchart illustrating the overall process of software patch enhancement according to the present invention.

[0042] Figure 2 This is a flowchart of the joint type inference process of warehouse-level static analysis and large model in this invention. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0044] Reference Figure 1-2 ,

[0045] Example 1: Fixing patch failure caused by missing null value type validation

[0046] This example uses the Aider agent as the candidate patch generated by the Django framework. The issue corresponding to this patch requires the implementation of a function to query user configuration information, but the patch does not consider the case where the query result is empty, and directly accesses the properties of the returned object, which throws an AttributeError exception during test execution.

[0047] The specific processing procedure is as follows:

[0048] S1: The system receives the candidate patch along with the corresponding Django code repository and test information. After parsing the patch, it determines that the modified file is utils.py, the modified function is get_user_config, and the variable to be analyzed is config_obj.

[0049] S2: The unified difference format validation and the syntax parsing of the newly added code both passed smoothly.

[0050] S3: The system constructs an abstract syntax tree for the Django repository, locating the definition source of the variable `config_obj` as the call result of `UserConfig.objects.filter`, and discovers the usage of null value checks for this type of query result in multiple modules of the repository. The system further constructs a control flow graph for the `get_user_config` function and performs reach-definition analysis. Based on iterative calculations using `INn = ⋃p∈pred(n) OUTp` and `OUTn = GENn ∪ (INn \ KILLn)`, it concludes that `config_obj` may be a `QuerySet` object or a null value after the query.

[0051] S4: The system distills the return value type annotation of the filter method and the code snippets in the repository that perform if exists checks on the filter results, forming the type context package of this variable.

[0052] S5: Static inference suggests that `config_obj` may be of type `QuerySet` or `None`, but Django ORM's lazy evaluation mechanism makes it impossible for static tools to determine the specific element type. The system submits the context package and candidate types to the large language model. The model, combined with Django framework usage conventions, confirms that explicit handling of empty results is required and outputs corresponding type validation suggestions.

[0053] S6: The system sends the original patch and type suggestions into the rewrite model. While maintaining the original repair intent, the model adds a check if config_obj is not None, accessing its attributes only if the object exists, otherwise returning the default configuration.

[0054] S7: The system re-executes format, syntax, and static type checks on the rewritten patch, then applies the patch and runs tests in the isolated environment. All tests pass, and finally the enhanced patch and related verification records are output.

[0055] This embodiment demonstrates that, without altering the original Aider generation process, this patch enhancement scheme effectively improves the patch's test pass rate by identifying null value risks through static analysis and supplementing type verification with a large model.

[0056] Example 2: Fixing Patch Failure Caused by Misjudgment of Complex Data Structure Types

[0057] This example uses an Agentless agent as the candidate patch generated for a Flask project. The issue corresponding to this patch involves converting the JSON request body submitted by the frontend into an internal data object. However, because the patch treats all fields as strings, it fails to recognize the nested dictionary and list types, causing subsequent data processing to throw a TypeError exception.

[0058] The specific processing procedure is as follows:

[0059] S1: The system receives the candidate patch, the corresponding Flask code repository, and test information. After parsing the patch, it determines that the modified file is handlers.py, the modified function is parse_payload, and the variable to be analyzed is payload_data.

[0060] S2: The format and syntax checks of the patch passed successfully.

[0061] S3: The system constructs an abstract syntax tree for the Flask repository, tracing the origin of the `payload_data` variable back to the return value of the `request.get_json` method, and finding multiple instances of dictionary retrieval and list traversal operations on this variable in the repository. The system constructs a control flow graph for the `parse_payload` function and performs reach-definition analysis to obtain the type differentiation of this variable in different execution branches.

[0062] S4: The system distills the return type annotation of the get_json method, the way existing utility functions in the repository handle nested data structures, and the calling conventions of this function in multiple places, forming a context package containing evidence of cross-file usage.

[0063] S5: Static inference determines that payload_data is a dictionary, but it cannot determine the value type corresponding to each key. The system submits the context package to the large language model. The model combines common patterns of request body parsing in the Flask framework with existing data transformation tools in the code repository to finely determine whether a specific key corresponds to a nested dictionary or a list of strings, and outputs accurate type mapping suggestions.

[0064] S6: The system inputs the original patch and type mapping suggestions into the rewrite model, and the model generates the correct type conversion logic accordingly, calls a special conversion function for nested dictionaries, and iterates through the string list.

[0065] S7: After the system completes all verifications, it applies patches and runs tests in the isolation sandbox, and all tests pass.

[0066] This embodiment demonstrates that the patch enhancement scheme obtains the complete usage pattern of variables through static program analysis across files, and effectively solves the problem of type misjudgment in complex data structures by combining the semantic refinement capabilities of a large language model.

[0067] Experimental data and effect verification

[0068] The impact of this patch enhancement scheme on the patch pass rate of the three software engineering intelligent agents is shown in the table below:

[0069] Evaluation Dimensions Aider Agentless AutoCodeRover average improvement Original patch pass count 80 82 94 85.3 Number of patches approved after enhancement 91 92 102 95.0 Net increase in the number of patches approved +11 +10 +8 +9.7 Original patch pass rate 26.67% 27.33% 31.33% 28.44% Improved patch pass rate 30.33% 30.67% 34.00% 31.67% Increase in pass rate +3.66 percentage points +3.34 percentage points +2.67 percentage points +3.22 percentage points Relative gain rate 13.75% 12.20% 8.51% 11.49%

[0070] Table 1 shows the comprehensive enhancement effects of this patching scheme on three different software engineering agents across multiple evaluation dimensions. The data indicates that this scheme achieved a net increase in the number of patch passes and a positive improvement in the pass rate for all three agents. The average pass rate increased from 28.44% to 31.67%, an increase of 3.22 percentage points, with an average relative gain of 11.49%. The Aider agent showed the most significant improvement, with the pass rate increasing from 26.67% to 30.33%, and a relative gain of 13.75%. These results verify that this scheme has good general adaptability and stable, consistent enhancement effects across different agents.

[0071] The following table shows a categorized summary of patches successfully fixed by this patch enhancement solution:

[0072] Improper handling of complex data structures 13 44.8% Before the fix, treating all nested JSON as strings caused type errors; after the enhancement, cross-file analysis identifies the actual usage patterns of the data structure, generating the correct logic for recursively transforming nested dictionary and list elements. Missing necessary type or null value checks 8 27.6% Before the fix, directly using potentially nullable method return values ​​caused runtime exceptions; after the enhancement, null value risk points were identified through reach-definition analysis, and type validation and null value fallback handling were added to the critical path. Basic data type conversion error 8 27.6% Before the fix, data of different types were directly concatenated or processed; after the enhancement, operand types are identified through static type inference, and explicit type conversion is added to ensure operational safety. total 29 100% —

[0073] As shown in Table 2:

[0074] The 29 patches successfully fixed by this patch enhancement solution were categorized and statistically analyzed according to defect type. Improper operation of complex data structures was the most common type of defect, accounting for 44.8% of all successful fixes. This percentage indicates that the solution's technical advantages in handling nested containers, complex data types, and multi-level data structures are most prominent. The lack of necessary type or null value checks and basic data type conversion errors each accounted for 27.6% of the problems, totaling more than half, indicating that type safety issues are prevalent in agent-generated patches. A comparison of typical changes before and after the fix demonstrates that this solution, through the combined effects of repository-level static analysis, control flow graph data flow tracing, and mixed type inference, can adopt differentiated enhancement strategies for different defect types, validating the comprehensive applicability and effectiveness of this solution in fixing various types of defects.

[0075] As can be seen from the above embodiments and experimental data, the software patch enhancement method and system proposed in this invention, which integrates static program analysis and large language model type inference, can effectively enhance the type security and applicability of candidate patches, significantly improve the patch test pass rate, and reduce the risk of patch failure due to improper type handling, without modifying the internal structure of the original software engineering agent. This is achieved through a series of technical means such as pre-validation of format and syntax, analysis of repository-level abstract syntax trees and control flow graphs, calculation of data flow to definition, hybrid type inference of static and large language models, and multi-layer quality verification.

[0076] In this invention, various candidate patches are integrated without altering the original software engineering agent's internal generation process. Before the patches enter in-depth analysis, rigorous format validation and syntax checks are performed to intercept candidate patches that do not conform to the unified difference format standard or contain syntax errors, effectively avoiding the waste of subsequent computing resources on unapplicable patches. The abstract syntax tree parsing of the complete code repository allows for the systematic retrieval and utilization of rich information such as variable definitions, assignments, function signatures, method calls, and cross-file usage relationships, providing a definite and traceable evidentiary basis for type inference and effectively improving the accuracy and reliability of type inference.

[0077] This invention organically integrates the determinism of static analysis with the semantic understanding capabilities of a large language model. Static type inference can provide accurate type conclusions for literals, container constructions, and simple expressions, while the large language model, constrained by static evidence, refines its judgments on complex nested structures, user-defined types, and framework-specific domain semantics, reducing type misjudgments and format violations that are prone to occur when the large model operates alone. The context distillation module filters out information directly related to type judgment from a large number of intermediate analysis results and compresses it into a variable-level evidence package. This ensures the traceability of evidence while effectively reducing the input length and computational cost of the large language model, significantly improving the applicability and test pass rate of patches, and effectively reducing the risk of patch failure due to improper type handling.

[0078] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0079] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A software patching enhancement method that integrates static program analysis and large language model type inference, characterized in that: Includes the following steps: S1: Receive candidate unified difference patch P, target code repository R, ​​problem description I, and optional test T; parse the target files, modified blocks, added lines, and deleted lines in P to form a set of modified files F, a set of modified functions M, and a set of variables to be analyzed V; Candidate patches are generated by any auto-repair agent without requiring changes to its internal structure; S2: Perform multi-level uniform difference format validation, checking diff --git, ---, +++, file paths, and @@ modification block markers; stop if the format does not meet the requirements; extract newly added code lines and restore them to parsable segments, and build the AST with the parser; if there are syntax errors, record them and prevent further analysis; S3: Parse the repository source files to construct the AST, retrieve variable definitions, assignments, etc. around V; construct the CFG for the affected functions, and perform definition reach analysis: calculate IN, GEN, KILL, and OUT, iterate to a fixed point, and obtain the possible definition sources and type changes of the variables; S4: Retain type-related information from the analysis results, including assignments, function signatures, return statements, method calls, property accesses, container operations, configuration items, etc., and compress them into variable-level context packages to reduce the length of LLM inputs and maintain traceability of evidence; S5: Static inference provides candidate types for literals, containers, expressions, etc.; when uncertain, it provides candidate types, evidence fragments, and context to the LLM for semantic refinement; outputs variable identifiers, candidate types, confidence levels, and supporting evidence. S6: Input the original patch, problem description, context, and type suggestions into the rewrite model, keeping the format intact; S7: Revalidate the format and path, parse the AST again, call mypy to check the type, apply patches to the isolated environment and run the test; if successful, output the refined patch, evidence and logs; if unsuccessful, output the diagnosis.

2. The software patching enhancement method integrating static program analysis and large language model type inference according to claim 1, characterized in that: In step S1, the system receives candidate unified difference patches, target code repositories to be patched, corresponding software problem descriptions, and optional failure test information generated by any software engineering intelligent agent or automatic repair tool. The system parses the target file path, the location and range of the modified block, the newly added code lines starting with a plus sign, and the deleted code lines starting with a minus sign from the candidate patches, and forms the set of modified files involved in this patch, the set of affected functions, and the set of variables that need to be analyzed in detail.

3. The software patching enhancement method integrating static program analysis and large language model type inference according to claim 1, characterized in that: In step S2, firstly, a multi-level unified difference format verification is performed on the candidate patch to check whether the patch header contains the diff --git flag, the old file path represented by three minus signs, the new file path represented by three plus signs, and the modification block start flag, which contains the start line number and context line number information. If the format verification fails, the system outputs the specific error location and terminates the subsequent type analysis process. At the same time, it can return the format error information to the original agent to request the regeneration of the patch. After the format validation passes, the system extracts new code lines that start with a plus sign and are not part of the file header from each modified block, restores these code lines according to their respective functions or code blocks to form independently parsable code fragments, and then uses the parser of the corresponding programming language to build an abstract syntax tree.

4. The software patching enhancement method integrating static program analysis and large language model type inference according to claim 1, characterized in that: In step S3, the system parses all source files in the target code repository and constructs a complete abstract syntax tree. Based on the set of variables to be analyzed determined in step S1, the system retrieves the definition location, assignment operation, function parameter passing, return type, container construction expression, method call, and cross-file usage location of each variable within the syntax tree. For functions affected by patches, the system constructs a control flow graph, where nodes correspond to statements or basic blocks, and edges correspond to possible execution path transitions. Based on this, the system performs definition reach analysis, calculating the valid definition set at the entry point and the valid definition set at the exit point for each node in the control flow graph. For any node n in the control flow graph, the system denotes pred(n) as the set of all predecessor nodes, i.e., there exist directed edges pointing to all nodes n; INn represents the set of valid definitions at the entrance of node n, OUTp represents the set of valid definitions at the exit of any predecessor node p, and the set of valid definitions at the entrance of node n is equal to the union of the sets of valid definitions at the exits of all predecessor nodes; GENn represents the set of definitions generated by node n itself, KILLn represents the set of definitions covered and eliminated by node n, and the set of valid definitions at the exit of node n is equal to the union of the remaining parts of GENn and INn after removing KILLn; the above relationships are expressed mathematically as follows: INn = ⋃p ∈ pred(n) OUTp OUTn = GENn ∪ INn \ KILLn The system iteratively updates the ingress and egress sets of all nodes according to the two formulas mentioned above, using the OUT set calculated in this round as the input for the next round of iteration. This process is repeated until the IN and OUT sets of all nodes no longer change, reaching the fixed point of data flow analysis.

5. The software patching enhancement method integrating static program analysis and large language model type inference according to claim 1, characterized in that: In step S4, the system filters out information items directly related to type judgment from a large number of intermediate results generated by the repository-level static analysis. This information includes the assignment expression of the variable, the parameter and return value type annotations in the function signature, the expression in the function return statement, the receiver and parameter type of the method call, the target object type of the attribute access, the read and write operations of container elements, and the usage pattern of the same variable in other modules.

6. The software patching enhancement method integrating static program analysis and large language model type inference according to claim 1, characterized in that: In step S5, during the static type inference process, literal expressions are directly assigned the corresponding basic type, container creation operations such as list construction and dictionary construction are inferred for their container type, and for general expressions, function call return values, and variables on the definition propagation chain, the system performs forward propagation of candidate types on the control flow graph. When static analysis cannot determine the internal element type of a complex nested container, the specific type of a user-defined class, or the semantic type of a specific domain, the system submits the variable-level context package formed in step S4, the candidate type list inferred in the static phase, and the corresponding abstract syntax tree and control flow graph evidence fragments to the large language model.

7. The software patching enhancement method integrating static program analysis and large language model type inference according to claim 1, characterized in that: In step S6, the system inputs the original candidate patch, the software problem description text, the context fragment of the code modified by the patch, and the structured type suggestion output in step S5 into the patch rewriting model. When generating the refined patch, the rewriting model is required to completely retain all file header information, modification block start markers, and line prefix symbols in the original candidate patch, while limiting the scope of modification to the code area necessary to achieve the problem fix.

8. The software patching enhancement method integrating static program analysis and large language model type inference according to claim 1, characterized in that: In step S7, the system first performs a unified difference format verification on the rewritten refinement patch, including integrity checks on file paths and modified block markers, to ensure that the patch can be used normally by standard version control tools. The system then re-executes abstract syntax tree parsing on the newly added or modified lines of code in the refinement patch to confirm the correctness of the syntax. Next, it calls the static type checker to perform consistency checks on the relevant code for type annotation and type operations.

9. A software patching enhancement system that integrates static program analysis and large language model type inference, characterized in that, Includes the following modules: The input interface module is used to receive candidate patches, target code repositories, problem descriptions and test information generated by the original software engineering intelligent agent, and to standardize the received data. The patch analysis module is used to parse the target file path, modified block position, added code line and deleted code line in the candidate patch to form a set of modified files and a set of variables to be analyzed. It performs uniform difference format verification on the candidate patch, checks the file header path identifier and modified block start mark, performs abstract syntax tree parsing on the added code line to check the syntax correctness, and outputs the error position and terminates the subsequent process when the verification fails. The repository-level code analysis module is used to parse source files in the target code repository and build a complete abstract syntax tree. It retrieves the definitions, assignments, function parameters, return values, method calls, and cross-file usage locations of variables around the set of variables to be analyzed. It constructs control flow graphs for functions affected by patches and performs definition reach analysis. It iteratively calculates the effective definition set of the entry point and the effective definition set of the exit point for each node until a fixed point is reached. The context distillation module is used to extract assignment expressions, function signatures, return statements, method calls, property accesses, container operations, and cross-module usage patterns directly related to type judgment from repository-level analysis results. It compresses the extracted information and removes duplicate and irrelevant content. The hybrid type inference module is used to initiate the static type inference process, assign basic types to literals, infer container types from container constructions, perform forward propagation of candidate types for expressions and return values, and submit variable-level context packages and candidate type lists to the large language model for semantic refinement when static analysis cannot determine complex nested structures or user-defined types. The output includes structured type suggestions containing variable identifiers, candidate types and confidence scores, and supporting evidence chains. The patch rewrite module is used to input the original candidate patches, problem descriptions, code context and structured type suggestions into the patch rewrite model, keep the file header, modification block markers and line prefixes unchanged, supplement type checking, type conversion, null value handling and data structure operations within the scope of necessary repair, prioritize the reuse of existing tools and design patterns in the code library, and output refined patches; The verification output module is used to perform uniform difference format verification, abstract syntax tree parsing verification, and static type consistency verification on the refined patch. It applies the patch in an isolated sandbox and runs the target project test. When the test passes, it outputs the refined patch and verification record. When it fails, it outputs diagnostic information and sets minimum permissions and audit records for network access and sensitive file operations.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the software patch enhancement method that integrates static program analysis and large language model type inference as described in any one of claims 1 to 8.

Images