Computer system and method for supporting review of patch plan of source code

Abstract

To realize the review of a patch plan with high accuracy by using a generation AI.SOLUTION: A computer system is accessibly connected to a source code database, a patch database for storing a patch plan, and a text generation system, executes a review for determining whether or not the patch plan is applicable, and holds a prompt template for instructing output of a result of the review. The computer system executes a first process of analyzing a dependency relationship between code fragments constituting the source code to generate dependency relationship information indicating a dependency relationship between a correction code fragment including a correction content of a bug and another code fragment and a second process of selecting a code fragment having a dependency relationship with the correction code fragment based on the dependency relationship information, inserting a patch proposal, the correction code fragment, and the selected code fragment into a prompt template to generate a prompt, transmitting the prompt to the text generation system, and acquiring a result of a review of the patch proposal.SELECTED DRAWING: Figure 8

Description

[Technical Field]

[0001] The present invention relates to a technology for fixing bugs in source code using generative AI. [Background technology]

[0002] A technique called APR (Automated Program Repair) is known for debugging work in software development (see, for example, Non-Patent Document 1). By using this technique, patches (patch proposals) for fixing bugs can be automatically generated.

[0003] In some cases, APR generates a large number of patch proposals. In this case, the source code to which the patch proposals have been applied is tested, and patch proposals that pass the test are output to the user. The user then reviews the output patch proposals for suitability of the specifications and the effectiveness of bug fixes.

[0004] When the number of patch proposals is large, the number of patch proposals to be reviewed also increases, which poses a problem of increasing the burden on the user. To address this issue, a technology is known that uses a generation AI to automatically review proposals (see, for example, Non-Patent Document 2). [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] K. Liu et al., “TBar: Revisiting Template-based Automated Program Repair”, ISSTA2019, 2019, pp. 31-42. [Non-patent document 2] PR-Agent, https: / / github.com / Codium-ai / pr-agent [Non-patent document 3] L. Gazzola et al., “Automatic Software Repair: A Survey”, IEEE Transactions on Software Engineering, vol. 45, pp. 34-67, January 2019 Summary of the Invention [Problem to be solved by the invention]

[0006] In the technology described in Non-Patent Document 2, only the patch proposal is input. In this case, the context before and after the correction is lost, which may result in an inaccurate review. To address this issue, a solution can be considered in which the source code is input along with the patch proposal. However, since there is a limit to the number of tokens that can be input to the generation AI, there are cases in which it is not possible to input source code. Another problem is that inputting information unrelated to the corrections reduces the accuracy of the review.

[0007] The present invention aims to provide a technology that uses generative AI to enable highly accurate review of patch proposals. [Means for solving the problem]

[0008] A representative example of the invention disclosed in the present application is as follows: A computer system includes a processor and a storage device connected to the processor, and is accessible to a source code database storing a plurality of source code fragments constituting a program, a patch database storing proposed patches for fixing bugs contained in the source code, and a text generation system that performs natural language processing using a large-scale language model, and performs a review to determine whether the proposed patches are applicable and holds a prompt template for instructing output of the review results, wherein the processor executes a first process of analyzing dependencies between code fragments constituting a target source code and, based on the results of the analysis, generating dependency information representing a modified code fragment containing a fix for a bug in the proposed patch and its dependency with other code fragments, and a second process of selecting a code fragment that has a dependency relationship with the modified code fragment based on the dependency information, inserting the proposed patch, the modified code fragment, and the selected code fragment into the prompt template to generate a prompt, transmitting the prompt to the text generation system, and obtaining a result of the review of the proposed patch from the text generation system. [Effects of the Invention]

[0009] According to the present invention, a highly accurate review of patch proposals can be realized using a text generation system (generative AI). Problems, configurations, and effects other than those described above will become clear from the following description of the embodiments. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 illustrates an example of a system configuration according to a first embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of a hardware configuration of a computer that configures the program modification support system according to the first embodiment. [Figure 3] FIG. 10 is a diagram illustrating an example of a source code according to the first embodiment. [Figure 4] FIG. 10 is a diagram illustrating an example of a test code according to the first embodiment. [Figure 5] FIG. 10 is a diagram illustrating an example of an analysis result of the source code according to the first embodiment. [Figure 6] FIG. 10 is a diagram illustrating an example of a prompt template according to the first embodiment. [Figure 7] FIG. 2 is a diagram illustrating an example of a data structure of a patch DB according to the first embodiment. [Figure 8] 10 is a flowchart illustrating an example of a review support process executed by the program modification support system according to the first embodiment. [Figure 9A] FIG. 10 is a diagram showing an example of a response output by the text generation system of the first embodiment. [Figure 9B] FIG. 10 is a diagram showing an example of a response output by the text generation system of the first embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of a screen displayed on the terminal according to the first embodiment. [Figure 11] FIG. 10 is a diagram illustrating an example of a system configuration according to a second embodiment. [Figure 12] FIG. 11 illustrates an example of a data structure of a patch DB according to the second embodiment. [Figure 13] FIG. 10 is a diagram illustrating an example of a screen displayed on a terminal according to a second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, embodiments of the present invention will be described with reference to the drawings. However, the present invention should not be construed as being limited to the description of the embodiments shown below. Those skilled in the art will readily understand that the specific configuration can be changed without departing from the spirit or intent of the present invention.

[0012] In the configuration of the invention described below, the same or similar configurations or functions are denoted by the same reference numerals, and redundant explanations will be omitted.

[0013] In this specification, the terms "first," "second," "third," etc. are used to identify components and do not necessarily limit the number or order.

[0014] In this specification, a review is defined as a determination as to whether or not a proposed patch can be applied. [Example]

[0015] Fig. 1 is a diagram illustrating an example of a system configuration according to the first embodiment. Fig. 2 is a diagram illustrating an example of a hardware configuration of a computer that constitutes the program modification support system according to the first embodiment.

[0016] The system of the first embodiment includes a program modification support system 100, a text generation system 101, and a terminal 102. The program modification support system 100 is connected to the text generation system 101 and the terminal 102 via a network such as a LAN (Local Area Network).

[0017] The text generation system 101 is a system that performs natural language processing using a large-scale language model (generative AI). The large-scale language model is a natural language processing model constructed using a large amount of text data, and can perform various natural language processing tasks. The large-scale language model accepts prompts containing task content, such as questions written in natural language, understands the meaning of the task content, and generates and outputs answers.

[0018] The program modification support system 100 executes a test of a program consisting of at least one source code, and if the test fails, generates a patch proposal for correcting a bug in the source code. The program modification support system 100 also reviews the patch proposal using a text generation system 101.

[0019] The program modification support system 100 is configured from a computer 200 as shown in Fig. 2. The computer 200 has a processor 201, a network interface 202, a main memory device 203, and a secondary memory device 204. The hardware elements are connected via a bus 205. The computer 200 may have input devices such as a keyboard and a mouse, and an output device such as a display.

[0020] The processor 201 executes a program stored in the main memory device 203. The processor 201 executes processing in accordance with the program, thereby operating as a functional unit (module) that realizes a specific function. In the following explanation, when a processing is explained using a functional unit as the subject, it indicates that the processor 201 is executing a program that realizes the functional unit.

[0021] The network interface 202 connects to external systems and devices via a network. The main storage device 203 is a memory or the like, and stores various information and programs executed by the processor 201. The secondary storage device 204 is a hard disk drive (HDD), solid state drive (SSD), or the like.

[0022] The program modification support system 100 includes a patch generation unit 110, a source code analysis unit 111, and a review support unit 112. The program modification support system 100 may also include functional units (not shown), such as a test execution unit.

[0023] The program modification support system 100 also holds a source code DB 120 , a test code DB 121 , test information 122 , source code analysis information 123 , a prompt template 124 , and a patch DB 125 .

[0024] The patch generation unit 110 identifies the location of a bug in a program and generates a patch proposal for fixing the bug. A possible method for identifying the location of the bug is, for example, a method using the technology described in Non-Patent Document 3. A possible method for generating a patch proposal is, for example, a rule-based method as described in Non-Patent Document 1. Another possible method is to generate a patch proposal using a large-scale language model.

[0025] It should be noted that an external system may generate patch proposals and transmit them to the program modification support system 100. In this case, the program modification support system 100 does not need to include the patch generation unit 110.

[0026] The source code analysis unit 111 analyzes the dependencies of code fragments that make up the source code. Here, a code fragment is an operator, an identifier, an expression, etc. included in the source code. Furthermore, the source code analysis unit 111 generates source code analysis information 123 that represents the dependencies between the code fragment containing the bug fix and other code fragments based on the dependencies of the code fragments. In this embodiment, the source code analysis unit 111 generates a dependency graph with the code fragment containing the bug fix as the source code analysis information 123. The method of analyzing the dependencies of code fragments in source code is a well-known technique, so details will be omitted.

[0027] In the following description, a code fragment containing a bug fix will be referred to as a "fixed code fragment."

[0028] The review support unit 112 generates a prompt using the patch proposal, the source code analysis information 123, and the prompt template 124, and sends the prompt to the text generation system 101.

[0029] It should be noted that with regard to the functional units of the program modification support system 100, multiple functional units may be combined into one functional unit, or one functional unit may be divided into multiple functional units for each function.

[0030] Here, the data structure of the information managed by the program modification support system 100 will be described.

[0031] The source code DB 120 is a database for managing source code. For example, source code such as that shown in FIG. 3 is stored in the source code DB 120. The source code is managed in association with program identification information. In the following description, the source code to be modified is referred to as target source code. The source code DB 120 stores source code for a plurality of programs and source code corresponding to the execution modules of libraries. The source code DB 120 may be held by a system different from the program modification support system 100.

[0032] The test code DB 121 is a database for managing test codes for executing tests. For example, test codes as shown in Fig. 4 are stored in the test information 122. Note that the test code DB 121 may be held by a system different from the program modification support system 100.

[0033] The test information 122 is information for managing the results of tests using test codes. The test information 122 stores data relating the identification information of the source code to be tested, the identification information of the test code used, and the test results.

[0034] The source code analysis information 123 is information for managing the dependency relationships between a modified code fragment and other code fragments in the target source code. The source code analysis information 123 is, for example, a dependency relationship graph as shown in FIG.

[0035] In a dependency graph, the number of steps (distance) from the starting node to the target node corresponds to the strength of the dependency. The stronger the dependency, the fewer the number of steps.

[0036] The prompt template 124 is a template of a prompt to be input to the text generation system 101. For example, a prompt template 124 as shown in FIG. 6 is conceivable. By using the prompt template 124 of FIG. 6, it is possible to generate a prompt that instructs output of the review results of a proposed patch and the thought content during the review. If the proposed patch is determined to be applicable, the reason for the determination is output as the thought content, and if the proposed patch is determined to be inapplicable, feedback or a proposed revision is output as the thought content. By referring to the thought content, the user can efficiently perform their own review.

[0037] 6 is an example and is not intended to be limiting. The prompt template 124 may include test code, test results, etc. Furthermore, the prompt template 124 may be one that prompts a user to make a decision based on three options: applicable, inapplicable, and indeterminable, instead of two options: applicable and inapplicable.

[0038] The patch DB 125 is a database for managing patch proposals generated by the patch generation unit 110. The patch DB 125 stores, for example, a table 700 as shown in Fig. 7. Here, the table 700 will be described.

[0039] The table 700 stores entries each including an ID 701, a target line 702, a patch 703, an application 704, and an option 705. One entry corresponds to one patch proposal.

[0040] ID 701 is a field that stores the ID of the entry. Target line 702 is a field that stores the position (line number) of the code fragment to be modified in the target source code. Patch 703 is a field that stores a patch proposal.

[0041] Application 704 is a field for storing the results of the review by the large-scale language model (the result of determining whether or not the proposed patch can be applied). Option 705 is a field for storing the thought contents of the large-scale language model, etc.

[0042] Next, the processing executed by the program modification support system 100 will be described.

[0043] The program modification support system 100 executes a test on the target source code based on user input, etc., and stores the test results in the test information 122. The program modification support system 100 identifies the location of a bug in source code for which the test failed, and generates a patch proposal for fixing the bug contained in the identified bug location. The program modification support system 100 registers the patch proposal in the patch DB 125. At this time, the application 704 and option 705 are left blank.

[0044] The program modification support system 100 executes a review support process for the generated patch proposal. Fig. 8 is a flowchart illustrating an example of the review support process executed by the program modification support system 100 of the first embodiment. Figs. 9A and 9B are diagrams illustrating an example of a response output by the text generation system 101 of the first embodiment.

[0045] The source code analysis unit 111 executes a source code analysis process (step S101), and based on the analysis results, generates a dependency graph representing the dependency relationships of code fragments starting from the modified code fragments of each patch plan, as shown in FIG. 5.

[0046] The review support unit 112 initializes a variable N (step S102). The variable N is a variable that represents the number of steps (distance) from the modified code fragment in the dependency graph. Here, the variable N is set to 0.

[0047] The review support unit 112 starts a loop process of patch proposals and selects one patch proposal from the table 700 (step S103). Hereinafter, the selected patch proposal will be referred to as a target patch proposal.

[0048] The review support unit 112 refers to the dependency graph and identifies nodes (code fragments) within a distance N from the origin node corresponding to the modified code fragment of the target patch draft (step S104).

[0049] At this time, the review support unit 112 calculates the number of tokens for the starting node and the identified nodes. If the number of tokens in the prompt including all code fragments corresponding to the starting node and the identified nodes is greater than the upper limit of the number of tokens, the review support unit 112 selects a predetermined number of nodes from the identified nodes so that the number of tokens in the prompt is equal to or less than the upper limit of the number of tokens. For example, the review support unit 112 preferentially selects nodes that are close in distance, or randomly selects nodes.

[0050] The review support unit 112 generates a prompt (step S105) using the target patch proposal, the code fragment to be modified, the identified code fragment, and the prompt template 124. In the case of the prompt template 124 shown in Fig. 6, the review support unit 112 generates a prompt by inserting the code fragment to be modified and the identified code fragment into {code fragment} and inserting the target patch proposal into {patch proposal}.

[0051] The review support unit 112 sends a prompt to the text generation system 101 (step S106). When the review support unit 112 receives a response from the text generation system 101, it stores the variable N, the ID 701 of the entry corresponding to the target patch proposal, and data associating the response in the work area. FIGS. 9A and 9B are diagrams showing examples of responses. FIG. 9A shows the response when the patch proposal is applicable, and FIG. 9B shows the response when the patch proposal is inapplicable.

[0052] In step S107, the review support unit 112 determines whether or not the processing has been completed for all patch proposals (step S107).

[0053] If the processing has not been completed for all patch proposals, the review support unit 112 selects a new target patch proposal and executes the processing from step S104 onwards.

[0054] When the processing for all patch proposals is completed, the review support unit 112 determines whether or not the termination condition is met (step S108).

[0055] The termination conditions can be as follows: (Termination condition 1) The number of applicable patch proposals is smaller than a threshold. (Termination condition 2) The number of applicable patch plans is greater than the number of applicable patch plans in the previous loop process.

[0056] Termination condition 1 means that the number of applicable patch proposals has reached the number of patch proposals that the user can review. Termination condition 2 means that the review accuracy of the large-scale language model has decreased. As mentioned in the problem section, adding a code fragment that is not related to fixing a bug will decrease the review accuracy. In this example, a failure to narrow down the applicable patch proposals, i.e., an increase in the number of applicable patch proposals, is treated as a decrease in review accuracy.

[0057] If it is determined that the termination condition is not satisfied, the review support unit 112 adds 1 to the variable N (step S109), and then returns to step S103.

[0058] If it is determined that the termination condition is met, the review support unit 112 updates the patch DB 125 (step S110).

[0059] If termination condition 1 is adopted, the review support unit 112 writes the answers for each patch plan obtained in the current loop processing to the application 704 and option 705 of each entry in the table 700. If termination condition 2 is adopted, the review support unit 112 writes the answers for each patch plan obtained in the previous loop processing to the application 704 and option 705 of each entry in the table 700.

[0060] The review support unit 112 outputs the review result to the terminal 102 (step S111), and ends the review support process. In this embodiment, the review result of the patch proposals that are determined to be applicable is output. Fig. 10 is a diagram showing an example of a screen displayed on the terminal 102 in the first embodiment.

[0061] The screen 1000 displays the review results output from the review support unit 112, and includes a patch proposal list 1010 and an OK button 1020.

[0062] The patch proposal list 1010 includes entries each including an ID 1011, a target line 1012, a patch 1013, and an option 1014. One entry corresponds to one patch proposal. The ID 1011, the target line 1012, the patch 1013, and the option 1014 are the same fields as the ID 701, the target line 702, the patch 703, and the option 705. The OK button 1020 is a button that is operated when confirmation is complete.

[0063] In this embodiment, methods, fields, etc. are defined as code fragments, but the granularity of code fragments can be set arbitrarily. For example, a command statement may be defined as a code fragment.

[0064] According to Example 1, by including the correction portion (the correction code fragment) and the code fragment related to the correction portion, it is possible to have the generative AI (large-scale language model) review the patch proposal with high accuracy. [Example]

[0065] In the second embodiment, the results of the user's review of the proposed patch are reflected. The second embodiment will be described below, focusing on the differences from the first embodiment.

[0066] FIG. 11 is a diagram illustrating an example of a system configuration according to the second embodiment.

[0067] The system configuration of the second embodiment is the same as that of the first embodiment. The hardware configuration of the program modification support system 100 of the second embodiment is the same as that of the first embodiment.

[0068] In the second embodiment, the program modification support system 100 includes a feedback receiving unit 113. The feedback receiving unit 113 receives modifications to the review results from the user.

[0069] In addition, in the second embodiment, the data structure of the patch DB 125 is different from that in the first embodiment. Fig. 12 is a diagram showing an example of the data structure of the patch DB 125 in the second embodiment.

[0070] The entries of table 700 stored in patch DB 125 newly include flag 706. Flag 706 is a field that stores a flag indicating whether the review results of the proposed patch have been modified by the user. If the review results of the proposed patch have been modified, "1" is stored, and if the review results of the proposed patch have not been modified, "0" is stored. "0" is set as the default.

[0071] The prompt template 124 of the second embodiment differs from that of the first embodiment in that it is provided with a section for inserting an output example.

[0072] First, a method for correcting a review of a proposed patch will be described. Fig. 13 is a diagram showing an example of a screen displayed on the terminal 102 of the second embodiment.

[0073] The screen 1000 includes a patch proposal list 1010 , an OK button 1020 , and a Modify button 1030 .

[0074] The entries stored in the patch proposal list 1010 now include a selection 1015 and a reason 1016. The selection 1015 is a field for selecting an entry to be corrected. The reason 1016 is a field for storing the reason for correcting the review result and the user's thoughts on the review.

[0075] When correcting the review results, the user operates the box for selection 1015, inputs the reason for correcting the review results in reason 1016, and then presses the correct button 1030. In this case, a correction request including ID 1011 and reason 1016 is sent to the program correction support system 100. When the program correction support system 100 receives a correction instruction, it writes reason 1016 into option 705 of the entry whose ID 701 matches ID 1011, and also updates flag 706 to "1."

[0076] In the second embodiment, some of the review support processing is different from that in the first embodiment. Specifically, the method of generating a prompt is different. The review support unit 112 inserts the code fragment to be modified and the identified code fragment into {code fragment}, and inserts the target patch proposal into {patch proposal}. Furthermore, the review support unit 112 obtains the patch 703, application 704, and option 705 of the entry whose flag 706 is "1" from the table 700, and inserts them into the prompt template 124.

[0077] By including the user's review results in the prompts, the accuracy of the generative AI (large-scale language model) reviews can be improved.

[0078] The present invention is not limited to the above-described embodiments, but includes various modifications. For example, the above-described embodiments are provided to explain the present invention in detail, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, some of the configurations of each embodiment can be added to, deleted from, or replaced with other configurations.

[0079] Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The present invention can also be realized by software program code that implements the functions of the embodiments. In this case, a storage medium on which the program code is recorded is provided to a computer, and a processor included in the computer reads the program code stored in the storage medium. In this case, the program code itself read from the storage medium implements the functions of the above-described embodiments, and the program code itself and the storage medium on which it is stored constitute the present invention. Examples of storage media for providing such program code include flexible disks, CD-ROMs, DVD-ROMs, hard disks, solid-state drives (SSDs), optical disks, magneto-optical disks, CD-Rs, magnetic tapes, non-volatile memory cards, and ROMs.

[0080] Furthermore, the program code that realizes the functions described in this embodiment can be implemented in a wide range of program or script languages, such as assembler, C / C++, perl, Shell, PHP, Python, and Java (registered trademark).

[0081] Furthermore, the program code of the software that realizes the functions of the embodiments may be distributed via a network and stored in a storage means such as a computer's hard disk or memory, or in a storage medium such as a CD-RW or CD-R, and the processor of the computer may read and execute the program code stored in the storage means or storage medium.

[0082] In the above-described embodiment, the control lines and information lines are shown as those considered necessary for the explanation, and not all control lines and information lines are necessarily shown in the product. All components may be interconnected. [Explanation of symbols]

[0083] 100 Program Modification Support System 101 Text Generation System 102 terminals 110 Patch Generation Unit 111 Source Code Analysis Unit 112 Review Support Department 113 Feedback Reception Department 120 Source Code DB 121 Test Code DB 122 Test Information 123 Source Code Analysis Information 124 prompt templates 125 Patch DB 200 calculator 201 processor 202 Network Interface 203 Main storage 204 Secondary storage device 205 Bus 1000 screens

Claims

1. 1. A computer system comprising: a processor and a storage device connected to the processor; a source code database storing a plurality of source codes constituting a program, a patch database storing patch proposals for correcting bugs contained in the source code, and a text generation system that performs natural language processing using a large-scale language model; a prompt template for executing a review to determine whether the proposed patch is applicable and for instructing output of the review results; The processor: a first process of analyzing dependencies between code fragments constituting the target source code and generating dependency information representing dependencies between a modified code fragment including a bug fix in the patch proposal and other code fragments based on the results of the analysis; a second process of selecting the code fragment having a dependency relationship with the modified code fragment based on the dependency information, inserting the proposed patch, the modified code fragment, and the selected code fragment into the prompt template to generate a prompt, sending the prompt to the text generation system, and obtaining a result of the review of the proposed patch from the text generation system; A computer system that executes the above.

2. 2. The computer system of claim 1, In the first process, the processor generates a dependency graph starting from the modified code fragment as the dependency information; In the second process, the processor: a computer system configured to repeatedly execute a loop process that identifies code fragments whose distance from the modified code fragment is within a range equal to or less than a threshold value while changing a threshold value indicating the distance from the modified code fragment, selects a predetermined number of code fragments from the identified code fragments, generates the prompt, sends the prompt to the text generation system, and obtains the results of the review of the patch proposal from the text generation system.

3. 3. The computer system according to claim 2, The processor selects a predetermined number of the code fragments from the identified code fragments so that the number of tokens in the prompt is equal to or less than an upper limit.

4. 3. The computer system according to claim 2, A computer system characterized in that the processor terminates the loop processing and outputs the review results of the previous loop processing when the number of review results indicating applicability in the current loop processing is greater than the number of review results indicating applicability in the previous loop processing.

5. 3. The computer system according to claim 2, The processor: providing an interface that displays the results of the review indicating applicability; accepting, via the interface, modifications to the results of the review; A computer system characterized in that, in the loop processing, the prompt is generated including the content of corrections made as a result of the review.

6. 2. The computer system of claim 1, The computer system is characterized in that the prompt is a prompt that instructs output of the thought contents of the large-scale language model in the review together with the result of the review.

7. 2. The computer system of claim 1, The computer system is characterized in that the review result is either that the proposed patch is applicable, that the proposed patch is not applicable, or that it is impossible to determine.

8. A method for supporting review of a patch proposal executed by a computer system, comprising: The computer system a processor and a storage device connected to the processor; a source code database storing a plurality of source codes constituting a program, a patch database storing patch proposals for correcting bugs contained in the source code, and a text generation system that performs natural language processing using a large-scale language model; a prompt template for executing a review to determine whether the proposed patch is applicable and for instructing output of the review results; The patch draft review support method includes: a first step in which the processor analyzes dependencies of code fragments constituting the target source code, and generates dependency information representing dependencies between a modified code fragment including a fix for a bug in the proposed patch and other code fragments based on the results of the analysis; a second step in which the processor sends a prompt generated using the prompt template to the text generation system and obtains a result of the review of the proposed patch from the text generation system; Including, The second step includes: the processor selecting the code fragment having a dependency relationship with the modified code fragment based on the dependency relationship information; and generating the prompt by inserting the patch proposal, the modified code fragment, and the selected code fragment into the prompt template.

9. 9. The patch draft review support method according to claim 8, the first step includes a step of generating, by the processor, a dependency graph starting from the modified code fragment as the dependency information; In the second step, a threshold indicating a distance from the modified code fragment is changed, the processor identifying the code fragments whose distance from the modified code fragment is within the threshold range or less, and selecting a predetermined number of the code fragments from among the identified code fragments; the processor repeatedly generates the prompt, sends the prompt to the text generation system, and obtains a result of the review of the patch draft from the text generation system.

10. 10. The patch draft review support method according to claim 9, A method for supporting review of a patch proposal, comprising a step in which the processor selects a predetermined number of the code fragments from the identified code fragments so that the number of tokens in the prompt is equal to or less than an upper limit.

Images