A code commit log automatic generation method based on control flow graph modeling

Abstract

This invention discloses an automatic code commit log generation method based on control flow graph modeling. First, it obtains the new source code changes to be committed and determines whether the code commit log generation model has been trained. If not, it builds and trains the model until convergence. Then, a control flow graph generation tool is used to generate control flow graphs before and after the source code changes. A control flow fusion graph is constructed, and features are extracted from the graph. The change sequence of the source code and the features of the control flow fusion graph are input into the code commit log generation model to obtain the source code change log. Finally, the source code changes and the source code change log are committed and saved to the code repository. This invention can generate accurate and high-quality code commit logs, helping developers understand the entire code commit process and providing effective assistance to maintainers to quickly understand version evolution. It greatly saves manpower and time costs in software development and maintenance, and reduces the difficulty of software quality maintenance.

Description

Technical Field

[0001] This invention relates to a method for automatically generating code commit logs based on control flow graph modeling. It constructs a control flow fusion graph based on the control flow graphs before and after source code changes, and automatically generates code commit logs by modeling the semantic changes corresponding to source code changes. This method belongs to the field of automated software quality auxiliary maintenance technology in computer technology. Background Technology

[0002] Software is a collection of computer data and instructions organized in a specific order. It includes not only computer programs that can run on a computer, but also the documentation associated with those programs. Software is a core element of information systems, and its quality maintenance plays a crucial role in its continuous iteration and development. We typically use software version control systems to track different versions of files and the source code of software projects, as well as to coordinate the work of multiple developers who may be working on the same set of files simultaneously. Modern version control systems include GitHub. GitHub is an open-source code hosting platform where users can view other people's projects, create static web pages, manage plugins, edit code online, and host code. GitHub records the entire software iteration process, providing crucial evidence for subsequent software maintenance. When developers commit code, they are often required to submit short commit logs to document the changes. Commit logs summarize the semantic changes in the code using natural language and help developers quickly understand the high-level intent behind the code changes without delving into the detailed implementation. Therefore, high-quality commit logs are essential for developers to quickly understand the evolution of versions.

[0003] We typically write commit logs manually, but this is extremely time-consuming and labor-intensive. Furthermore, there's currently no unified standard for commit log formatting, and developers often neglect to write them when committing. A report from the open-source community SourceForge shows that approximately 14% of the commit logs in over 23,000 open-source Java projects are empty. Empty or low-quality commit logs significantly increase the difficulty for developers in code review and fixing. In fact, if commit log generation could be automated, with an automated tool generating a natural language description of each source code modification and committing it to the code repository along with the changes, it would greatly reduce the burden on those committing code and significantly improve developer efficiency in future software maintenance. However, current technologies struggle to capture semantic changes in code modifications, posing a significant challenge to automating commit log generation. Therefore, a method for automatically generating high-quality code commit logs is urgently needed. Summary of the Invention

[0004] The summary section of this application is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0005] To address the problems and shortcomings of existing technologies, this invention aims to provide an automatic code commit log generation method based on control flow graph modeling. This method effectively models the changes in code execution flow before and after developers modify source code, based on the code's control flow graph. This generates accurate, high-quality code commit logs, helping developers complete the code commit process, saving manpower and time costs in software development and maintenance, and reducing the difficulty of software quality maintenance. This solves the problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] This invention discloses a method for automatically generating code commit logs based on control flow graph modeling, which mainly includes the following steps:

[0008] Step 1: Obtain the new source code changes to be submitted;

[0009] Step 2: Build and train the code commit log generation model until it converges;

[0010] Step 3: Serialize the source code modifications to obtain its modification sequence;

[0011] Step 4: Use a control flow graph generation tool to generate control flow graphs before and after the source code modification, construct a control flow fusion graph, and extract features from the graph;

[0012] Step 5: Input the change sequence of the source code modification and the features of the control flow fusion graph into the code commit log generation model to obtain the source code change log;

[0013] Step 6: Submit the source code changes and source code change log to the code repository.

[0014] Furthermore, in step 2, the code commit log generation model is established and trained. The code commit log generation model includes an encoder and a decoder, and specifically includes the following training steps:

[0015] Step 2.1: Obtain a large number of historical source code changes and their corresponding code commit logs to construct a code training set;

[0016] Step 2.2: Initialize the parameters of the code commit log generation model;

[0017] Step 2.3: Serialize the historical source code modifications to obtain its modification sequence;

[0018] Step 2.4: Use a control flow graph generation tool to generate control flow graphs before and after the historical source code modification, construct a historical control flow fusion graph, and extract features from the graph;

[0019] Step 2.5: Use the encoder to encode and learn the features of the historical control flow fusion graph and the modification sequence of the historical source code, and output the result.

[0020] Step 2.6: Use the decoder to process the output of the encoder and generate training code submission logs autoregressively;

[0021] Step 2.7: Calculate the cross-entropy loss by comparing the training code submission logs with the benchmark code submission logs;

[0022] Step 2.8: Update the model parameters using gradient backpropagation based on the cross-entropy loss, and stop iterating on the code training set until convergence.

[0023] Furthermore, in step 2.5, the encoder performs encoding learning and output on the features of the historical control flow fusion graph and the modification sequence of the historical source code. The encoder part adopts a multi-granularity multi-head self-attention layer, which is processed by the feedforward network layer after residual connection and layer normalization. The graph node sequence in the features of the historical control flow fusion graph is a code block composed of one or more lines of code statements, which belongs to coarse-grained representation. The modification sequence of the historical source code is a component of the code statements, which belongs to fine-grained representation. The encoder encodes the graph node sequence in the features of the historical control flow fusion graph and the modification sequence of the historical source code simultaneously.

[0024] Furthermore, in step 2.5, the multi-head self-attention layer in the encoder at multiple granularities fully learns intra-granularity features and cross-granularity features, including a feature transfer part and a feature fusion part, specifically including the following steps:

[0025] Step 2.5.1: Initialize the sequences in the coarse-grained and fine-grained representations and vectorize them;

[0026] Step 2.5.2: Perform self-aggregation on the fine-grained sequence to obtain a new representation of the fine-grained sequence;

[0027] Step 2.5.3: Add the new representation of the fine-grained sequence to the coarse-grained sequence, and obtain the new representation of the coarse-grained sequence through feature transformation and layer normalization;

[0028] Step 2.5.4: Update using the new representation of the fine-grained sequence and the new representation of the coarse-grained sequence via different multi-head self-attention layers.

[0029] Furthermore, in step 2.6, the decoder processes the result of the encoder to generate historical code submission logs in an autoregressive manner. The decoder part adopts a Transformer decoder, which consists of a masked multi-head attention layer, a multi-head attention layer, and a feedforward network layer. Each layer is followed by residual connection and layer normalization operations. The decoder accepts the fine-grained feature representation part of the encoder output, and the output is processed through a fully connected layer and layer normalization to generate the code submission logs.

[0030] Furthermore, in step 2.7, the cross-entropy loss is calculated by comparing the training code submission logs with the benchmark code submission logs. Represented as,

[0031]

[0032] Where x is the sequence of changes to the input historical source code, s represents the changes to the historical source code sequence, and y... <tFor the generated output sequence before time t, y t Let y be the output at time t, θ be all the parameters of the model, and k be the length of the output sequence y.

[0033] Furthermore, in step 4, a control flow graph generation tool is used to generate control flow graphs before and after the source code modification, construct a control flow fusion graph, and extract features from the graph. Specifically, this includes the following steps:

[0034] Step 4.1: Construct the control flow graph of the original source code before modification, and add node type markers to indicate whether the changes have been made;

[0035] Step 4.2: Construct the control flow graph of the modified source code and add node type markers to indicate whether the changes have been made;

[0036] Step 4.3: Merge the control flow graphs of the source code before and after the modification to construct a fused control flow graph containing the changes;

[0037] Step 4.4: Extract the features from the control flow fusion graph, including the connection relationships between nodes and the types of nodes.

[0038] This invention also discloses an automatic code commit log generation device based on control flow graph modeling, comprising: an acquisition module for acquiring source code changes; a training module for training a code commit log generation model until the model converges; a serialization module for performing serialization operations on the source code changes and historical source code changes to obtain a corresponding change sequence; a generation and extraction module for generating control flow graphs before and after the source code changes and historical source code changes using a control flow graph generation tool, constructing a fusion graph with historical control flow and extracting features from the graph; an output module for inputting the change sequence of the source code changes and the features of the fusion graph with historical control flow into the code commit log generation model to obtain a source code change log; and a commit module for committing and saving the source code changes and the source code change log to the code repository.

[0039] The present invention also discloses an electronic device, comprising: at least one processor, and a memory communicatively connected to the at least one processor; the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps of the above-described method for automatically generating code commit logs based on control flow graph modeling.

[0040] The present invention also discloses a computer storage medium storing a computer program, characterized in that the computer program, when executed by a processor, implements the steps of the above-described method for automatically generating code commit logs based on control flow graph modeling.

[0041] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0042] This invention provides an automatic code commit log generation method based on control flow graph modeling. This method effectively models the changes in code execution flow before and after source code modifications based on control flow graphs. First, the new source code changes to be committed are obtained. Then, it is determined whether the code commit log generation model has been trained. If not, the model is built and trained until convergence; otherwise, the source code changes are directly serialized to obtain the change sequence. Next, a control flow graph generation tool is used to generate control flow graphs before and after the source code changes. A control flow fusion graph is constructed, and features are extracted from the graph. The change sequence and features of the control flow fusion graph are input into the code commit log generation model to obtain the source code change log. Finally, the source code changes and the source code change log are committed and saved to the code repository. This invention can generate accurate and high-quality code commit logs, helping developers understand the entire code commit process and providing effective assistance to maintainers to quickly understand version evolution. It greatly saves the manpower and time costs of software development and maintenance, and reduces the difficulty of software quality maintenance. Attached Figure Description

[0043] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application.

[0044] In the attached diagram:

[0045] Figure 1 This is a flowchart illustrating the main steps in an embodiment of the present invention.

[0046] Figure 2 This is a flowchart illustrating the main execution steps in an embodiment of the present invention.

[0047] Figure 3 This is a flowchart illustrating the steps of constructing a control flow fusion graph and extracting features in an embodiment of the present invention.

[0048] Figure 4 This is a flowchart illustrating the execution steps of the training code submission log generation model in an embodiment of the present invention. Detailed Implementation

[0049] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0050] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0051] This invention discloses a method for automatically generating code commit logs based on control flow graph modeling. The following will describe this disclosure in detail with reference to the accompanying drawings and embodiments.

[0052] During software development and maintenance, updates and version iterations are constantly implemented to meet evolving requirements. Developers then modify the source code in the code repository, including but not limited to adding new features, fixing existing software issues, and refactoring the software framework. Typically, we need to acquire these source code changes and deliver them to an automated software quality support device for processing and submission. In this process, the automated software quality support device analyzes the source code changes, automatically outputs corresponding code commit logs, and then the source code changes and their logs are committed to the local or remote code repository. If there are still uncommitted source code changes, the device continues to acquire and analyze new source code changes; otherwise, the code commit is complete. The core of this invention is the automatic generation of code commit logs based on control flow graph modeling.

[0053] Reference Figures 1 to 2 As shown, the present invention mainly includes the following steps:

[0054] Step 1: Obtain the new source code changes to be submitted;

[0055] Step 2: Build and train the code commit log generation model until it converges;

[0056] Step 3: Serialize the source code modifications to obtain the modified sequence;

[0057] Step 4: Use a control flow graph generation tool to generate control flow graphs before and after source code modification, construct a control flow fusion graph, and extract features from the graph;

[0058] Step 5: Input the sequence of source code changes and the features of the control flow fusion graph into the code submission log generation model to obtain the source code change log;

[0059] Step 6: Submit source code changes and save the source code change log to the code repository.

[0060] Specifically, this invention first acquires the source code modifications. Then, it determines whether a pre-trained code commit log generation model already exists. If not, it builds and trains the model until convergence. If a model already exists, it serializes the acquired source code modifications to obtain a modification sequence. Next, a control flow graph generation tool is used to generate control flow graphs before and after the source code modifications. Based on these graphs, a fusion control flow graph containing the modifications is constructed, and relevant features are extracted from this fusion graph, including the correspondence between nodes and source code modifications, and the connections between nodes. The fusion graph provides a better representation of the learned source code modifications, thus automating the documentation of the code commit process. The modification sequence and the features of the fusion graph are then input into the code commit log generation model to output the source code modification log. Finally, the source code modifications and the source code modification log are saved to the code repository.

[0061] like Figure 3 As shown, in step 2, a code commit log generation model is built and trained. The code commit log generation model includes an encoder and a decoder, and specifically includes the following training steps:

[0062] Step 2.1: Obtain a large number of historical source code changes and their corresponding code commit logs to construct a code training set;

[0063] Step 2.2: Initialize the parameters of the code commit log generation model;

[0064] Step 2.3: Serialize the historical source code modifications to obtain its modification sequence;

[0065] Step 2.4: Use a control flow graph generation tool to generate control flow graphs before and after the historical source code changes, construct a historical control flow fusion graph, and extract features from the graph;

[0066] Step 2.5: Use an encoder to encode and learn the features of the historical control flow fusion graph and the modification sequence of the historical source code;

[0067] Step 2.6: Use the decoder to process the encoder's output and autoregressively generate training code submission logs;

[0068] Step 2.7: Calculate the cross-entropy loss by comparing the training code submission logs with the benchmark code submission logs;

[0069] Step 2.8: Update the model parameters using gradient backpropagation based on cross-entropy loss, and stop iterating on the code training set until convergence.

[0070] Specifically, we obtain a large number of historical source code changes from modern software version control systems, such as GitHub. We serialize these historical source code changes and generate control flow graphs before and after the changes. Then, we construct a fused control flow graph containing the historical changes and extract relevant features from the graph. The relevant features in the fused historical control flow graph include the graph node sequence t = ... <t1,t2,…,t m >Graph node type tag sequence Graph adjacency matrix A∈R m ×m The mapping relationship M between nodes and source code token sequences is defined. The code commit log generation model adopts an encoder-decoder structure. The encoder receives the aforementioned relevant features and historical source code modification sequences as input, while modeling the sequentiality of historical source code and the structure of the control flow graph. The encoder effectively encodes the features of the input historical control flow fusion graph and the historical source code modification sequences, while the decoder uses the encoder's result as input to autoregressively generate training code commit logs. The cross-entropy loss is calculated between the generated training code commit logs and the benchmark code commit logs. The code commit log generation model is trained using this cross-entropy loss until the loss converges, resulting in the trained code commit log generation model.

[0071] Furthermore, the encoder part of the code commit log generation model, after residual connections and layer normalization, is fed to the feedforward network layer for processing. This multi-granularity multi-head self-attention layer and the feedforward network layer are stacked N times to finally obtain the encoder output. The encoder part implements a multi-granularity multi-head self-attention layer, for a graph node sequence t of length m... <t1,t2,…,t m > and a source code modification sequence x of length n = <x1,x2,…,x n Encoding is performed simultaneously. Since each node in the control flow graph is a block of code consisting of one or more lines of code statements, it represents a coarse-grained approach. In contrast, the source code sequence, being composed of code statements, represents a fine-grained approach.

[0072] In step 2.5, the multi-head self-attention layer in the encoder fully learns intra-granularity features and cross-granularity features, including feature propagation and feature fusion, specifically including the following steps:

[0073] Step 2.5.1: Initialize the sequences in the coarse-grained and fine-grained representations and vectorize them;

[0074] Step 2.5.2: Perform self-aggregation on the fine-grained sequence to obtain a new representation of the fine-grained sequence;

[0075] Step 2.5.3: The new representation of the fine-grained sequence is added and fused with the coarse-grained sequence, and the new representation of the coarse-grained sequence is obtained through feature transformation and layer normalization;

[0076] Step 2.5.4, update using new representations of fine-grained and coarse-grained sequences via different multi-head self-attention layers.

[0077] Specifically, before execution, the encoder needs to initialize two sequences at different granularities to obtain vectorization, represented as the fine-grained source code modification sequence x = Embedding. x ([x1,x2,…,x n ])∈R n×D and coarse-grained node sequences

[0078] Among them, Embedding x Embedding t and Embedding s These represent different feature embedding layers, where D is the dimension of the embedded feature vector. The multi-granularity self-attention layer uses two key steps to fully learn intra-granularity and cross-granularity features: feature propagation and feature fusion. In the feature propagation step, features from the fine-grained source code modification sequence x are passed to the coarse-grained node sequence t. The fine-grained features first self-aggregate to obtain a new representation of the fine-grained sequence, as shown in the following equation.

[0079]

[0080] in, This represents the aggregation result corresponding to the i-th node, where M represents the mapping relationship between nodes and the source code token sequence. Then, the aggregation result... Compared with the current coarse-grained representation t i The features are then added together, transformed using a fully connected layer, and then normalized to obtain a new coarse-grained sequence representation. The transfer process is represented by the following equation:

[0081]

[0082] Among them, W u and b u These represent the weights and bias parameters of the fully connected layer, while LayerNorm represents the layer normalization operation.

[0083] During the feature fusion step, the feature representations of the two granularities are updated through different multi-head self-attention layers. For the coarse-grained graph node sequence t, the updated coarse-grained representation is obtained by concatenating the results from the multi-head self-attention layers. If there are H attention heads, the update result is expressed as follows:

[0084]

[0085] Among them, W O ∈R D×D Let head1(t), ..., head be the learned mapping matrix. H The calculation of (t) is explained by the following process. For the h-th attention head, each element of the coarse-grained graph node sequence t is mapped by three different mapping matrices. The attention layer is mapped to three vectors: Query, Key, and Value. The calculation first uses the dot product of the Query and Key to calculate the correlation between elements. Then, the correlation between unconnected nodes is masked based on the connection relationships / adjacency matrix. The correlation is then normalized to between 0 and 1 using a softmax function. Finally, the Values ​​are weighted and summed based on the correlation to obtain the output of the self-attention layer. Therefore, the process of processing coarse-grained self-attention heads is represented by the following formula:

[0086]

[0087]

[0088]

[0089] Where d represents a scaling factor to avoid training instability, exp represents an exponential function, and e∈R m×m Represented as a correlation matrix, α∈R m×m The attention map obtained after normalization, head h (t) i For t i The feature representation obtained after updating by the h-th attention head. Finally, the head... h (t) by head h (t)1、head h (t)2、…、head h (t) m The stacking process is complete, thus updating each attention point.

[0090] For a fine-grained sequence of source code changes x, the updated fine-grained representation is also obtained by concatenating the results from multiple attention heads. If there are H attention heads, the update result is as follows:

[0091]

[0092] Among them, W O ∈R D×DLet head1(x),…,head be the learned mapping matrix. H The calculation of (x) is explained by the following process. For the h-th attention head, each element of the fine-grained source code modification sequence x is mapped by three different mapping matrices. The data is mapped to Query, Key, and Value vectors for attention calculation. Unlike the processing of node sequences, in the association calculation stage, source code sequence elements are not only associated with other source code sequence elements, but also with elements in the node sequence. This allows high-level features to be backpropagated to lower levels to enhance fine-grained representations. Therefore, the two association matrices u∈R... n×n and v∈R n×m It is calculated synchronously, as shown in the following formula.

[0093]

[0094]

[0095] in, Let d be the mapping matrix corresponding to the Query and Key mentioned above, where d is a scaling factor to avoid training instability. The correlation degree obtained from the above formula is normalized using a normalized exponential function, and the Value is weighted and accumulated based on the correlation degree to obtain the output of the self-attention layer. In summary, the process of processing fine-grained self-attention heads is represented by the following formula:

[0096]

[0097]

[0098]

[0099] Where exp represents the exponential function, β∈R n×n and γ∈R n×m Represented as the attention map obtained after normalization, head h (x) i Represented as x i The feature representation obtained after updating by the h-th attention head. Finally, the head... h (x) is from head h (x)1、head h (x)2、…、head h (x) n The stacking process is complete, thus updating each attention point.

[0100] The decoder employs a Transformer decoder, consisting of a masked multi-head attention layer, a cross-multi-head attention layer, and a feedforward network layer stacked together. Each layer is followed by a residual connection and layer normalization. Similarly, this structure is stacked N layers. The decoder receives the fine-grained feature representation from the encoder output. The output is then processed through a fully connected layer and layer normalization to obtain the training code submission log. The generated training code submission log is compared with the benchmark code submission log to calculate the cross-entropy loss, and the model is trained until the loss converges. The cross-entropy loss function is calculated. Represented as,

[0101]

[0102] Where x is the sequence of changes to the input historical source code, s represents the changes to the historical source code sequence, and y... <t For the generated output sequence before time t, y t Let y be the output at time t, θ be all the parameters of the model, and k be the length of the output sequence y.

[0103] Step 3 is similar to Step 2.3, the difference being the application object. In Step 3, we serialize the obtained source code modifications, while in Step 2.3, we serialize the obtained historical source code modifications. Serialization is the process of converting the state information of an object into a form that can be stored or transmitted. The serialized code is stored on a storage medium, can be viewed or modified, and can be transmitted over a network. The obtained source code modifications need to include the currently modified code line and its context code lines, and these need to be flattened into a source code token sequence, marked as x= <x1,x2,…,x n At the same time, a marker sequence is used to preserve changes to the token sequence, marked as s= <s1,s2,…,s n > Here, s can take three values: -1, +1, and 0. -1 indicates deletion during modification, +1 indicates addition during modification, and 0 indicates no change during modification. The corresponding serialization of the target code commit log is represented as y = <y1,y2,…,y k >

[0104] like Figure 4 As shown, in step 4, a control flow graph generation tool is used to generate control flow graphs before and after the source code modification, construct a control flow fusion graph, and extract features from the graph. Specifically, this includes the following steps:

[0105] Step 4.1: Construct the control flow graph of the original source code before modification, and add node type markers to indicate whether the changes have been made;

[0106] Step 4.2: Construct the control flow graph of the modified source code and add node type markers to indicate whether the changes have been made;

[0107] Step 4.3: Merge the control flow graphs of the source code before and after the modification to construct a fused control flow graph containing the changes;

[0108] Step 4.4: Extract features from the control flow fusion graph, including the connection relationships between nodes and the types of nodes.

[0109] Specifically, step 4 is similar to step 2.4, the only difference being the application. Step 4 generates the control flow graph before and after the source code modification, as well as the fused control flow graph, while step 2.4 generates the control flow graph before and after the historical source code modification, as well as the historical fused control flow graph. The features of the fused control flow graph include the graph node sequence t = ... <t1,t2,…,t m >Graph node type tag sequence Graph adjacency matrix A∈R m×m The mapping relationship M between nodes and source code token sequences. To construct the control flow fusion graph, we first need to obtain the source code before modification and use existing control flow graph generation tools to construct the corresponding control flow graph. A control flow graph, also called a control flow diagram, is an abstract representation of a process or program, representing all paths traversed during program execution. It represents the possible flow of execution of all basic blocks within a process, reflecting the real-time execution process. Then, we add node types to the original control flow graph before modification. If a node remains unchanged, it is type 0; if a node is modified, it is type -1. The control flow graph containing node types is defined as (N, E, S), representing the set of nodes, the set of edges, and the set of node types, respectively. Therefore, the control flow graph before code modification is represented as CFG. old =(N old E old S old Similarly, construct the modified control flow graph and add node types to the original modified control flow graph. If a node remains unchanged, it is type 0; if a node has been modified, it is type 1. The modified control flow graph is then represented as CFG. new =(N new E new S new Next, the two control flow graphs are merged to construct a modified control flow fusion graph. During the merging process, we take the union of the node sets of the two control flow graphs as the new node set, the union of the edge sets of the two graphs as the new edge set, and the union of the node type sets of the two graphs as the new node type set. The constructed control flow fusion graph is represented as CFG. fuse =(N old ∩Nnew E old ∩E new S old ∩S new Furthermore, expand N old ∩N new This yields the node sequence t = <t1,t2,…,t m Correspondingly, S old ∩S new It can be expanded into a sequence of node type tags. And E old ∩E new It can also be written as an adjacency matrix A∈R m×m Let represent the connection relationship between nodes in the graph. For any node t i and t j When they are connected, A ij =1, A when not connected ij =0. Next, it is necessary to extract relevant features from the control flow fusion graph, including the graph node sequence t= <t1,t2,…,t m >Graph node type tag sequence Graph adjacency matrix A∈R m×m The mapping relationship M between nodes and source code token sequences. Specifically, in the one-to-many mapping relationship M between nodes and source code token sequences, any node t... i and source code token sequence x j That is, the source code token sequence x j Node t i If and only if x j ∈t i Time M(t) i ,x j ) = 1, otherwise M(t) i ,x j ) = 0.

[0110] To implement the above embodiments, this disclosure also proposes an automatic code commit log generation device based on control flow graph modeling, comprising: an acquisition module for acquiring source code changes; a training module for training a code commit log generation model until the model converges; a serialization module for performing serialization operations on the source code changes and historical source code changes to obtain a corresponding change sequence; a generation and extraction module for generating control flow graphs before and after the source code changes and historical source code changes using a control flow graph generation tool, constructing a fusion graph with historical control flow, and extracting features from the graph; an output module for inputting the change sequence of source code changes and the features of the fusion graph with historical control flow into the code commit log generation model to obtain a source code change log; and a submission module for submitting and saving the source code changes and source code change log to the code repository.

[0111] To implement the above embodiments, this disclosure also proposes an electronic device. This electronic device can be an electronic product with a processor and memory, such as a portable computer, desktop computer, etc. Furthermore, the electronic device includes at least one processor and memory, the memory being used to store executable instructions, and the processor being used to control the electronic device to execute the code commit log automatic generation method based on control flow graph modeling according to any embodiment of the present invention.

[0112] To implement the above embodiments, this disclosure also proposes a computer storage medium. This computer storage medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0113] A computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer storage medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer storage medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0114] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0115] The units described in some embodiments of this disclosure may be implemented in software or in hardware. The described units may also be located in a processor, and the names of these units do not necessarily limit the specific unit itself. The functions described above may be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that may be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0116] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A method for automatically generating code commit logs based on control flow graph modeling, characterized in that, Includes the following steps: Step 1: Obtain the new source code changes to be submitted; Step 2: Build and train the code commit log generation model until convergence; the code commit log generation model includes an encoder and a decoder, and specifically includes the following training steps: Step 2.1: Obtain a large number of historical source code changes and their corresponding code commit logs to construct a code training set; Step 2.2: Initialize the parameters of the code commit log generation model; Step 2.3: Serialize the historical source code modifications to obtain its modification sequence; Step 2.4: Use a control flow graph generation tool to generate control flow graphs before and after the historical source code modification, construct a historical control flow fusion graph, and extract features from the graph; Step 2.5: The encoder is used to encode and learn the features of the historical control flow fusion graph and the modification sequence of the historical source code. The encoder part adopts a multi-granularity multi-head self-attention layer, which is processed by the feedforward network layer after residual connection and layer normalization. The graph node sequence in the features of the historical control flow fusion graph is a code block composed of one or more lines of code statements, which belongs to coarse-grained representation. The modification sequence of the historical source code is a component of the code statements, which belongs to fine-grained representation. The encoder encodes the graph node sequence in the features of the historical control flow fusion graph and the modification sequence of the historical source code simultaneously. Step 2.5 specifically includes the following steps: Step 2.5.1: Initialize the sequences on the coarse-grained and fine-grained representations and vectorize them; Step 2.5.2: Perform self-aggregation on the fine-grained sequence to obtain a new representation of the fine-grained sequence. Step 2.5.3: Add the new representation of the fine-grained sequence to the coarse-grained sequence, and obtain the new representation of the coarse-grained sequence through feature transformation and layer normalization; Step 2.5.4: Update the sequence using the new representation of the fine-grained sequence and the new representation of the coarse-grained sequence through different multi-head self-attention layers. Step 2.6: Use the decoder to process the output of the encoder and generate training code submission logs autoregressively; Step 2.7: Calculate the cross-entropy loss by comparing the training code submission logs with the benchmark code submission logs; Step 2.8: Update the model parameters using gradient backpropagation based on the cross-entropy loss, and stop iterating on the code training set until convergence; Step 3: Serialize the source code modifications to obtain its modification sequence; Step 4: Use a control flow graph generation tool to generate control flow graphs before and after the source code modification, construct a control flow fusion graph, and extract features from the graph; Step 5: Input the change sequence of the source code modification and the features of the control flow fusion graph into the code commit log generation model to obtain the source code change log; Step 6: Submit the source code changes and source code change log to the code repository.

2. The method for automatically generating code commit logs based on control flow graph modeling according to claim 1, characterized in that: In step 2.6, the decoder processes the result of the encoder and generates historical code submission logs in an autoregressive manner. The decoder part adopts a Transformer decoder, which consists of a masked multi-head attention layer, a multi-head attention layer, and a feedforward network layer. Each layer is followed by residual connection and layer normalization operations. The decoder accepts the fine-grained feature representation part of the encoder output, and the output is processed through a fully connected layer and layer normalization to generate the code submission logs.

3. The method for automatically generating code commit logs based on control flow graph modeling according to claim 1, characterized in that, In step 4, a control flow graph generation tool is used to generate control flow graphs before and after the source code modification, construct a control flow fusion graph, and extract features from the graph. Specifically, this includes the following steps: Step 4.1: Construct the control flow graph of the original source code before modification, and add node type markers to indicate whether the changes have been made; Step 4.2: Construct the control flow graph of the modified source code and add node type markers to indicate whether the changes have been made; Step 4.3: Merge the control flow graphs of the source code before and after the modification to construct a fused control flow graph containing the changes; Step 4.4: Extract the features from the control flow fusion graph, including the connection relationships between nodes and the types of nodes.

4. An electronic device, characterized in that, include: At least one processor, and a memory communicatively connected to said at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the steps of the method according to any one of claims 1 to 3.

5. A computer storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 3.

Images