Automatic recognition of code changes

Abstract

This document describes embodiments for automatically identifying, recommending, and / or implementing changes to a legacy source code repository by leveraging knowledge gained from previous updates to other similar legacy code repositories. In some embodiments, data associated with a first version source code snippet can be applied as input to a machine learning model to generate new source code embeddings in a latent space. (One or more) reference embeddings can be identified in the latent space based on their (one or more) distances in the latent space to the new source code embeddings. (One or more) reference embeddings can be associated with individual changes made during (one or more) previous code repository updates. Based on the identified one or more reference embeddings, (one or more) changes to be made to the first version source code snippet to create a second version source code snippet can be identified, recommended, and / or implemented.

Description

Technical Field

[0001] The present application relates generally to automatic identification of code changes. Background Art

[0002] Software systems are built on a source code "base" that typically relies on and / or combines many independent software technologies, such as programming languages (e.g., Java, Python, C++), frameworks, shared libraries, runtime environments, and so on. Each software technology may evolve at its own pace and may include its own branches and / or versions. Each software technology may also depend on various other technologies. Therefore, the source code base of a large software system can be represented by a complex dependency graph.

[0003] Keeping software technology up to date is beneficial. Newer versions can include critical improvements that fix security vulnerabilities and / or bugs, as well as new features. Unfortunately, the resources required to keep these software technologies up to date can sometimes be prohibitive, especially as part of a specific software system's codebase. Consequently, many software systems aren't updated as frequently as they should be. Outdated software technology can lead to numerous problems, such as bugs, security vulnerabilities, and a lack of ongoing support. Summary of the Invention

[0004] The present invention describes a technique for automatically identifying, recommending, and / or automatically implementing changes to a legacy source code repository based on previous updates made to other similar legacy code repositories. Intuitively, multiple previous "migrations" or large updates of a complex software system code repository can be analyzed to identify the changes made. In some embodiments, machine learning and latent space embeddings can be used to preserve knowledge of these changes. When a new software system code repository similar to one or more of the previously updated code repositories is to be updated, machine learning and the previously mentioned latent space embeddings can be used to identify these previously implemented changes. Once identified, these changes can be automatically identified, recommended, and / or implemented. By automatically identifying, recommending, and / or implementing these changes, the time and expense of manually changing large amounts of source code snippets to correctly reflect changes to related software technologies on a dependency graph can be reduced or even eliminated.

[0005] In some embodiments, one or more machine learning models, such as graph neural networks ("GNNs") or sequence-to-sequence models (e.g., encoder-decoder networks, etc.), can be trained to generate embeddings based on source code snippets. These embeddings can capture semantic and / or syntactic properties of the source code snippets, as well as the context in which these snippets are deployed. In certain embodiments, these embeddings can take the form of "reference" embeddings that represent previous changes made to the source code snippets during previous migrations of the source code repository. In other words, these reference embeddings map or project previous codebase changes into a latent space. These reference embeddings can then be used to identify candidate changes for a new migration of a new source code repository.

[0006] As a non-limiting example of how a machine learning model configured with selected aspects of the present disclosure may be trained, in some embodiments, a first version source code snippet (e.g., version 1.1.1) may be used to generate a data structure such as an abstract syntax tree (“AST”). The AST may represent structures that appear in the first version source code snippet, such as variables, objects, functions, and the like, as well as the grammatical relationships between these components. Another AST may be generated for a second version source code snippet (e.g., 1.1.2), which may be the next version or “iteration” of the first version source code snippet. The two ASTs may then be used to generate one or more data structures, such as one or more change graphs, that represent one or more changes made to update the source code snippet from the first version to the second version. In some embodiments, a change graph may be generated for each change to the source code snippet during its evolution from the first version to the second version.

[0007] Once the change graph(s) are created, they can be used as training examples for training a machine learning model. In some embodiments, the change graph(s) can be processed using a machine learning (e.g., GNN or sequence-to-sequence) model to generate corresponding reference embeddings. In some embodiments, the change graph(s) can be labeled with information such as the type of change, which is used to map the changes to corresponding regions in the latent space. For example, a label "changed variable name" can be applied to one change, another label "changed API signature" can be applied to another change, and so on.

[0008] As more change graphs are fed into the machine learning model, these labels can be used as part of a loss function to determine whether comparable changes are correctly clustered together in the latent space. If the embeddings generated from changes of a particular change type (e.g., "changing a variable name") are not close enough to other embeddings of the same change type (e.g., closer to embeddings of other change types), the machine learning model can be trained, for example, using techniques such as gradient descent and backpropagation. This training process can be repeated on a large number of training examples until the machine learning model is able to accurately map change graphs, and more generally, data structures representing source code snippets, to regions of the latent space that are close to other syntactically / semantically similar data structures.

[0009] Once the machine learning model is trained, it can be used during an update of the software system code base to be updated to identify and, in some cases, automatically implement changes to various source code snippets in the code base. In some embodiments, data associated with a first version source code snippet of the code base to be updated can be applied as input to the trained machine learning model to generate embeddings. As during training, the data associated with the first version source code snippet can be a data structure such as an AST. However, unlike during training, the first version source code snippet has not yet been updated to the next version. Therefore, there is no second version source code snippet and no change graph.

[0010] Nevertheless, when a machine learning (e.g., GNN or sequence-to-sequence) model is used to process the AST or other data structure generated from the first version source code snippet, the subsequent source code embedding can be close to the reference embedding(s) in the latent space, which represent(s) changes made to similar (or even identical) source code snippets during the previous codebase migration. In other words, the first version source code snippet is mapped to the latent space to identify changes made to similar source code in similar situations in the past. These(s) changes can then be recommended and / or automatically implemented to update the first version source code snippet to the second version source code snippet.

[0011] In some embodiments, the distance between a source code embedding in the latent space and a reference embedding(s) representing past source code change(s) can be used to determine how to proceed, e.g., whether to recommend the change, automatically implement the change, or even whether to not recommend the change. These spatial relationships in the latent space (which can correspond to similarities) can be determined in various ways, such as using dot products, cosine similarity, and the like. As an example, if the reference embedding is within a first radius of the source code embedding in the latent space, the change represented by that embedding can be automatically implemented, e.g., without user confirmation. If the reference embedding is outside the first radius of the source code embedding but within a second radius of the source code embedding, the change represented by that embedding can be recommended to the user, but may require user confirmation, and so on. In some embodiments, a score can be assigned to a candidate change based on its distance from the source code embedding, and this score can be presented to the user, e.g., as a percentage match or confidence score, to help the user determine whether the change should be implemented.

[0012] In some embodiments where the source code embedding is similarly close to multiple reference embeddings, the changes represented by the multiple embeddings can be presented to a user (e.g., a software engineer) as candidate changes. In some cases where the multiple changes do not conflict with each other, the multiple changes can simply be automatically implemented.

[0013] While change types were mentioned above as potential labels for training data, this is not meant to be limiting. In addition to or in lieu of change types, labels indicating other characteristics may be assigned to training examples. For example, in some embodiments, in addition to or in lieu of change types, a change graph (or other data structure representing changes between source code versions) may be labeled as "good" changes, "bad" changes, "unnecessary" changes, "duplicate" changes, matching or not matching a preferred codec style, etc. These labels may be used in addition to or in lieu of change types or other type labels to further map the latent space. Later, when a new source code embedding is generated and found to be close to a reference embedding labeled "bad," the change represented by the reference embedding may not be implemented or recommended.

[0014] In some embodiments, a method performed by one or more processors is provided, the method comprising: applying data associated with a first version source code snippet as input to one or more machine learning models to generate a new source code embedding in a latent space; identifying one or more reference embeddings in the latent space based on one or more distances between the one or more reference embeddings and the new source code embedding in the latent space, wherein each of the one or more reference embeddings is generated by applying data indicating a change made to a reference first version source code snippet to produce a reference second version source code snippet as input to one or more of the machine learning models; and identifying one or more changes to be made to the first version source code snippet to create the second version source code snippet based on the identified one or more reference embeddings.

[0015] In various embodiments, the data associated with the first version of the source code snippet includes an abstract syntax tree ("AST") generated from the first version of the source code snippet. In various embodiments, one or more of the machine learning models includes a graph neural network ("GNN"). In various embodiments, the one or more changes are identified based on one or more lookup tables associated with one or more reference embeddings.

[0016] In various embodiments, the method further includes generating an output to be presented on one or more computing devices, wherein the output, when presented, recommends one or more changes to be considered for the first version of the source code snippet. In various embodiments, the method further includes automatically implementing the one or more changes in the first version of the source code snippet. In various embodiments, the first version of the source code snippet includes a source code file.

[0017] In another aspect, a method implemented using one or more processors may include obtaining data indicating a change between a first version of a source code snippet and a second version of the source code snippet; marking the data indicating the change with a change type; applying the data indicating the change as input to a machine learning model to generate a new embedding in a latent space; determining a distance in the latent space between the new embedding and a previous embedding in the latent space associated with the same change type; and training the machine learning model based at least in part on the distance.

[0018] Furthermore, some embodiments include one or more processors of one or more computing devices, wherein the one or more processors are operable to execute instructions stored in an associated memory, and wherein the instructions are configured to cause performance of any of the foregoing methods. Some embodiments also include one or more non-transitory computer-readable storage media storing computer instructions executable by the one or more processors to perform any of the foregoing methods.

[0019] It should be understood that all combinations of the above concepts and the additional concepts described in greater detail herein are contemplated as being part of the subject matter disclosed herein. For example, all combinations of the claimed subject matter appearing at the end of this disclosure are contemplated as being part of the subject matter disclosed herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 An example environment is schematically depicted in which selected aspects of the present disclosure may be implemented, according to various implementations.

[0021] Figure 2 is a block diagram of an example process flow.

[0022] Figure 3 Schematic showing an example of how to generate latent space embeddings using the machine learning model described in this article during inference.

[0023] Figure 4 Schematic showing an example of how latent space embeddings are generated during the training phase using the machine learning model described in this paper.

[0024] Figure 5 A flowchart illustrating an example method according to implementations disclosed herein is depicted.

[0025] Figure 6 Depicted is a flowchart illustrating another example method according to implementations disclosed herein.

[0026] Figure 7 An example architecture for a computing device is shown. DETAILED DESCRIPTION

[0027] Figure 1 An example environment is schematically depicted in which selected aspects of the present disclosure may be implemented, according to various implementations. Figure 1 Or any computing device depicted elsewhere in the figures may include logic, such as one or more microprocessors (e.g., a central processing unit or "CPU", a graphics processing unit or "GPU") that executes computer-readable instructions stored in memory; or other types of logic, such as an application-specific integrated circuit ("ASIC"), a field-programmable gate array ("FPGA"), etc. Figure 1 Some of the systems depicted in , such as the code knowledge system 102 , may be implemented using one or more server computing devices forming what is sometimes referred to as a “cloud infrastructure,” although this is not required.

[0028] The code knowledge system 102 may be configured to perform selected aspects of the present disclosure to assist one or more clients 110 1-P Update one or more corresponding legacy code bases 112 1-PEach client 110 may be, for example, an entity or organization, such as a business (e.g., a financial institution, a bank, etc.), a non-profit organization, a club, a university, a government agency, or any other organization that operates one or more software systems. For example, a bank may operate one or more software systems to manage the money under its control, including tracking deposits and withdrawals, tracking loans, tracking investments, etc. An airline may operate one or more software systems to book / cancel / rebook flight reservations, manage flight delays or cancellations, manage personnel associated with a flight (e.g., passengers, crew, and ground staff), manage airport slots, etc.

[0029] Many of these entities' software systems may be mission-critical. Even the smallest amount of downtime or failure can be highly disruptive or even catastrophic to the safety of both the entity and, in some cases, its customers. Furthermore, a given legacy codebase 112 may be relatively large, with a complex dependency graph. Consequently, portions of the entity 110 that runs the software system are often reluctant to update their legacy codebase 112.

[0030] The code knowledge system 102 can be configured to leverage knowledge of past code base updates or "migrations" to improve the efficiency of the process of updating the legacy code base underlying the physical software system. For example, the code knowledge system 102 can be configured to recommend specific changes to various source code snippets as part of the migration. In some embodiments, the code knowledge system 102 can even automatically implement the source code changes, for example, if there is sufficient confidence in the proposed source code changes.

[0031] In various implementations, the code knowledge system 102 may include machine learning ( Figure 1 ML) database 104, which includes information indicating one or more trained machine learning models 106 1-N These trained machine learning models 106 1-N Various forms may be employed, as described in greater detail below, including but not limited to graph neural networks, sequence-to-sequence models such as various flavors of recurrent neural networks (e.g., long short-term memory or “LSTM,” gated recurrent units or “GRU,” etc.), or encoder-decoders, as well as any other type of machine learning model that may be used to facilitate selected aspects of the present disclosure.

[0032] In some embodiments, the code knowledge system 102 may also access one or more latest code repositories 108 1-M In some embodiments, these latest code bases 108 1-M Can be used, for example, to train a machine learning model 106 1-N In some such embodiments, and as will be described in further detail below, the latest code base 1081-M Can be combined with other data to train machine learning models106 1-N , such as has been updated to produce the latest code base 108 1-M A non-latest codebase (not depicted) is shown. As used herein, "latest" does not imply a requirement that all source code in a codebase be the absolute latest version. Rather, "latest" can refer to a desired state of a codebase, whether that desired state is the latest version of the codebase, the latest version of the codebase considered "stable," the latest version of the codebase that meets some other criteria (e.g., meeting some security protocol or standard, depending on the specific library), etc.

[0033] In various embodiments, a client 110 that wishes to update its legacy code base 112 may establish an entity ( Figure 1 In some embodiments, the code knowledge system 102 can then obtain all or part of the client's legacy source code repository 112, for example, via one or more networks 114 (such as the Internet), and return data indicating recommended changes or even updated source code to the client 110. In other embodiments, for example, where the client's legacy code repository 112 to be updated is large, one or more representatives of the entity hosting the code knowledge system 102 can travel to the client's site(s) to perform the updates and / or make recommendations.

[0034] Figure 2 Is training a machine learning model 106 1-N A block diagram of example process flows that may be implemented in whole or in part by the code knowledge system 102 during training and / or during use of these models ("inference") to predict what changes should / could be made to the legacy code base 112. Training will be discussed first, followed by inference. Unless otherwise noted, Figure 2 The various components in may be implemented using any combination of hardware and computer-readable instructions.

[0035] Starting from the upper left portion, the code base 216 may include one or more source code snippets 218 of one or more types. 1-Q For example, in some cases, the first source code snippet 2181 may be written in Python, another source code snippet 2182 may be written in Java, another source code snippet 2183 may be written in C / C++, and so on. Additionally or alternatively, the element 218 1-QEach of the source code snippets 218 may represent one or more source code snippets from a particular library, entity, and / or application programming interface ("API"). Depending on the circumstances, each source code snippet 218 may include a subset of a source code file or an entire source code file. For example, a particularly large source code file may be broken down into smaller snippets (e.g., divided into functions, objects, etc.), while a relatively short source code file may remain intact throughout the processing.

[0036] Source code snippet 218 of code base 112 1-Q At least some of can be converted into alternative forms, such as graph or tree forms, in order to subject them to additional processing. Figure 2 Source code snippet 218 1-Q is processed to generate an abstract syntax tree (“AST”) 222 1-R . Both Q and R can be positive integers, and they can be equal to or unequal to each other. As previously described, the AST can represent structures that appear in a given source code snippet, such as variables, objects, functions, etc., as well as the grammatical relationships between these components. In some embodiments, during training, the AST 220 may include a first AST for a first version of the source code snippet (e.g., a "to be updated" version), another AST for a second version of the source code snippet (e.g., a "target version"), and a third AST that conveys (one or more) differences between the first source code snippet and the second source code snippet.

[0037] The dataset builder 224, which may be implemented using any combination of hardware and machine-readable instructions, may receive the AST 222 1-R As input, it generates as output various types of data that can be used for various purposes in downstream processing. For example, in Figure 2 , the dataset builder 224 generates a change graph 228, AST-AST data 230, and change tags 232 as "delta data" 226. The change graph 228 - which, as described above, can itself be in the form of an AST - can include one or more change graphs generated from one or more pairs of ASTs, which are generated from corresponding pairs of to-be-updated / target source code snippets. In other words, each source code snippet 218 can be mapped to an AST 222. Pairs of ASTs, one of the pair representing a first version of the source code snippet and the other representing a second version of the source code snippet, can be mapped to a change graph 228. Thus, each change graph 228 represents one or more changes made to update the source code snippet from the first (to-be-updated) version to the second (target) version. In some embodiments, a different change graph can be generated for each change to the source code snippet during its evolution from the first version to the second version.

[0038] Change type labels 232 may include labels assigned to change graphs 228 for training purposes. Each label may specify the type of change made to the source code snippet underlying the change graph under consideration. For example, each of change graphs 228 may be labeled with a corresponding change type from change type labels 232. The corresponding change type may be used to map the changes conveyed by change graphs 228 to corresponding regions in the latent space. For example, a label "change variable name" may be applied to one change in a source code snippet, another label "change function name" may be applied to another change in another source code snippet, and so on.

[0039] The AST2VEC component 234 can be configured to generate one or more feature vectors, i.e., "latent space" embeddings 244, from the incremental data 226. For example, the AST2VEC component 234 can apply the change map 228 as input to one or more machine learning models to generate corresponding latent space embeddings 244. The machine learning model can take various forms as described above, such as a GNN 252, a sequence-to-sequence model 254 (e.g., an encoder-decoder), and the like.

[0040] During training, the training module 250 may train a machine learning model such as a GNN 252 or a sequence-to-sequence model 254 to directly or indirectly generate the source code snippet 218. 1-Q Generate embeddings 244. These embeddings 244 can capture source code snippets 218 1-Q , semantic and / or syntactic properties of the snippets, as well as the context in which those snippets are deployed. In some embodiments, as multiple change graphs 228 are input to a machine learning model (particularly a GNN 252), the change type labels 232 assigned to them can be used as part of a loss function to determine whether comparable changes are correctly clustered together in the latent space. If the embeddings generated from a change of a particular change type (e.g., "changed variable name") are not close enough to other embeddings of the same change type (e.g., closer to embeddings of other change types), the GNN 252 can be trained, for example, using techniques such as gradient descent and backpropagation. This training process can be repeated on many training examples until the GNN 252 is able to accurately map change graphs, and more generally, data structures representing source code snippets, to regions in the latent space that are close to other syntactically / semantically similar data structures.

[0041] In particular, with GNN 252, the constituent ASTs of incremental data 226, which, recall, are generated from source code snippets and may include a change graph in AST form, may be manipulated as follows. Features (which may be manually selected or learned during training) may be extracted for each node of the AST to generate a feature vector for each node. Recall that the nodes of an AST may represent variables, objects, or other programming structures. Thus, the features of the feature vector generated for a node may include features like the variable type (e.g., integer, floating point number, string, pointer, etc.), name, operator(s) acting as operands on the variable, and the like. The feature vector of a node at any given point in time may be viewed as the "state" of that node.

[0042] At the same time, each edge of the AST can be assigned a machine learning model, such as a specific type of machine learning model or a specific machine learning model trained on specific data. For example, the edges representing "if" statements can each be assigned a first neural network. The edges representing "else" statements can also each be assigned a first neural network. The edges representing conditionals can each be assigned a second neural network. And so on.

[0043] Then, for each time step in a series of time steps, the feature vector or state of each node can be propagated along the edges / machine learning model to their neighbor nodes, for example, as a projection to the latent space. In some embodiments, the incoming node states to a given node at each time step can be summed (which is order-invariant), for example, summed with each other and summed with the current state of the given node. As more time steps pass, the radius of the neighbor nodes that affect the given node of the AST increases.

[0044] Intuitively, as the machine learning model is iterated more and more, knowledge about neighboring nodes is incrementally "incorporated into" the state of each node, accumulating more knowledge about increasingly distant neighbors in the state of a given node. In some embodiments, after performing some desired number of iterations, a "final" state for all nodes of the AST can be reached. This number of iterations can be a hyperparameter of the GNN 252. In some such embodiments, these final states can be summed to produce an overall state or embedding of the AST (e.g., 244).

[0045] In some embodiments, for the change graph 228, during processing using the GNN 252, edges and / or nodes that form part of a change can be weighted more heavily than other edges / nodes that remain constant between versions of the underlying source code snippet. Thus, the change(s) between versions of the underlying source code snippet can have a greater impact on the resulting state or embedding representing the entire change graph 228. This can promote clustering of embeddings generated from similar changes in the latent space, even if some of the context surrounding those embeddings differs.

[0046] For the sequence-to-sequence model 254, training can be implemented using implicit labels that appear in the sequence of changes to the underlying source code. Instead of training on the source and target ASTs, the entire change path from the first version of the source code snippet to the second version of the source code snippet can be used for training. For example, the sequence-to-sequence model 254 can be trained to predict an "update" sequence of source code elements representing an updated source code snippet based on a sequence of source code elements (e.g., tokens, operators, etc.). In some embodiments, both the GNN 252 and the sequence-to-sequence model 254 can be employed separately and / or simultaneously.

[0047] Once the machine learning models (e.g., 252-254) are fully trained, they can be used in the inference phase to help new clients migrate their codebases that have not yet been updated. Starting again from the upper left portion, codebase 216 can now represent the legacy codebase 112 of client 110. Unlike during training, during inference, codebase 216 can only include legacy source code that is to be updated. However, Figure 2 Many other operations in are similar to those in training.

[0048] Source code snippet to be updated 218 1-Q Used again to generate AST 222 1-R However, AST 222 1-RRather than being processed by dataset builder 224, they can simply be applied, for example, by AST2VEC component 234, as input to one or more of the trained machine learning models (e.g., 252, 254) to generate new source code embeddings in the latent space 244. One or more reference embeddings in the latent space can then be identified, for example, by change list ("CL") generator 246, based on respective distances in the latent space between the one or more reference embeddings and the new source code embeddings. As described above, each of the one or more reference embeddings can have been previously generated, for example, by training module 250, by applying data indicating changes made to a reference first version source code snippet to produce a reference second version source code snippet as input to one or more of the machine learning models (e.g., 252-254).

[0049] Based on the identified one or more reference embeddings, the CL generator 246 can identify one or more changes to be made to the (one or more) source code snippets to be updated to create (one or more) updated source code snippets. These recommended code changes (e.g., changed code generated from the code to be changed) can be output at block 248. Additionally or alternatively, in some embodiments, if the code change recommendation is determined with a sufficient confidence metric, the code change recommendation can be implemented without input from the user. In yet other embodiments, the code change recommendation can be automatically implemented in response to other events (such as one or more passing automatic code unit tests).

[0050] Figure 3 An example of how a source code snippet 350 can be embedded in a latent space 352 is shown. Figure 2 Various undepicted components process the source code snippet, source.cc 350, until its AST reaches the AST2VEC component 234. As previously described, the AST2VEC component 234 applies the AST generated from source.cc 350 on one or more machine learning models (such as GNN 252) to create embeddings into the latent space 352 (given by Figure 3 (indicated by the black circle in the figure).

[0051] exist Figure 3 In the example of , the previously described training process has been used to learn regions 354 of the latent space 352 that correspond to the types of changes 1-T T can be a positive integer equal to the number of Figure 2 The number of different change type labels 232 in the change graph 228 in the source code snippet. For example, the first region 3541 may correspond to a first change type (e.g., "change variable name"). The reference embedding ( Figure 3 A cluster of reference embeddings generated from a change graph representing changes to function names in a source code snippet may reside in the second region 3542. And so on. These regions 354 (and Figure 4 454) can be defined in various ways, such as by using the largest enclosing circle or "convex hull" of all existing / known embeddings of a particular change type.

[0052] exist Figure 3 In the example of , source.cc 350 is a source code snippet to be updated, for example, for a particular client 110. The embedding ( Figure 3 It is entirely possible that the black dots in the latent space 352 will be close to multiple different change types. This may be because the same or similar source code fragment included multiple types of changes when it was previously updated. Figure 3 In the example of , the embedding generated from source.cc 350 can be mapped to the first region 3541, the second region 3542 and the third region 3543 at the same time, as shown by region 354 1-3 The location of the dark spot within the intersection is shown.

[0053] To determine which changes to make and / or recommend, in various embodiments, one or more reference embeddings in latent space 352 may be identified based on one or more distances between the one or more reference embeddings in latent space 352 and the new source code embeddings (dark circles). Figure 3 These distances or "similarity" can be calculated in various ways, such as by cosine similarity, dot product, etc. In some implementations, the reference embedding(s) closest to the new source code embedding can be identified and used to determine the corresponding source code edit.

[0054] For example, in some embodiments, each reference embedding can be associated, for example in a lookup table and / or database, with one or more source code changes that generated the reference embedding. Assume that the closest reference embedding in the change variable name area 3541 is associated with a source code change that replaced the variable name "var1" with "varA." In some embodiments, a recommendation can be generated and presented, for example as an audio or video output, that recommends applying the same change to the source code base to be updated. In some embodiments, this output can convey the actual changes to be made to the code and / or comments related to the code changes.

[0055] In some embodiments, a confidence metric can be determined for such a change, e.g., a shorter distance between the new source code embedding and the closest reference embedding corresponds to a greater confidence. In some such embodiments, if the confidence metric is sufficiently large, e.g., meets one or more thresholds, the change can be automatically implemented without first prompting the user.

[0056] Figure 4 An example of how source code snippet 460 may be used to create a reference embedding and / or train a machine learning model such as GNN 252 is depicted. The first version of source code snippet 460 to be updated in this example is 1.0.0. In this example, the second or "target" version of source code snippet 460' is 1.0.1. Figure 4 As shown in , ASTs 464, 464' can be generated from first and second versions of source code snippets 460, 460', respectively. Assume for this example that the only change to the source code snippet between 1.0.0 and 1.0.1 is a change in the variable name, as reflected by the addition of a new node at the lower left portion of AST 464'.

[0057] The ASTs 464, 464' may be compared, for example, by the dataset builder 224, to generate a change graph 228 reflecting the change. The change graph 228 may then be processed, for example, by the AST2VEC 234 using a machine learning model such as the GNN 252 and / or the sequence-to-sequence model 254, to generate a latent space embedding as indicated by the arrows. In this example, the latent space embedding falls within region 4541 of the latent space 452, where other reference embeddings involving variable name changes are also found (in Figure 4 (represented again by small circles).

[0058] As part of training the machine learning model, in some embodiments, data indicating changes between a first version of a source code snippet and a second version of the source code snippet, such as a change graph 228, can be labeled with a change type (using 232). The change graph 228 can then be applied, for example by an AST2VEC component 234, as an input to a machine learning model (e.g., 252) to generate a new embedding in a latent space 452. Next, the distance in the latent space between the new embedding and a previous (e.g., reference) embedding in the latent space associated with the same change type can be determined and used to train the machine learning model. For example, if the distance is too large—e.g., greater than the distance between the new embedding and a reference embedding of a different change type—techniques such as backpropagation and gradient descent can be applied to alter (one or more) weights and / or parameters of the machine learning model. Eventually, after sufficient training, the reference embedding of the same change type will be in the latent space 452 (which can then be compared to the distance between the new embedding and the reference embedding of the different change type). Figure 3 The latent space 352 in (corresponding to) is clustered together.

[0059] Figure 5 is a flowchart illustrating an example method 500 for mapping a source code snippet to be updated to a latent space containing reference embeddings using a trained machine learning model, according to embodiments disclosed herein. For convenience, the operations of the flowchart are described with reference to a system that performs the operations. The system may include various components of various computer systems, such as one or more components of the code knowledge system 102. Furthermore, while the operations of method 500 are illustrated in a particular order, this is not intended to be limiting. One or more operations may be reordered, omitted, or added.

[0060] At block 502, the system may apply a first version of a source code snippet (e.g., Figure 3 The first version of the source code snippet is used as input to one or more machine learning models (e.g., 252) to generate a new source code embedding in the latent space (e.g., 352). The data associated with the first version of the source code snippet may include the source code snippet itself and / or may include another representation of the source code snippet, such as an AST (e.g., 222). In some embodiments, the source code snippet may be a portion of a source code file, or even the entire source code file.

[0061] At block 504, the system may identify one or more reference embeddings in the latent space based on one or more distances between the one or more reference embeddings and the new source code embedding. As previously explained, each of the one or more reference embeddings may have been generated by applying an instruction to a reference first version source code snippet ( Figure 4 460) is made to generate a reference second version source code snippet ( Figure 4 460 ') of the modified data (e.g., 228), generated as input to one or more of the machine learning models (e.g., as Figure 4 ). And in various embodiments, each reference embedding can be associated, for example in a lookup table and / or database, with one or more changes made to the source code underlying the reference embedding.

[0062] At block 506, the system may identify one or more changes to be made to the first version of the source code snippet to create the second version of the source code snippet based on the identified one or more reference embeddings. For example, the system may search a lookup table or database for one or more changes associated with the closest reference embedding.

[0063] At block 508, the confidence metric associated with the identification of block 506 can be compared to one or more thresholds. For example, the confidence metric can be determined based on the distance between the new source code embedding and the closest reference embedding in the latent space. For example, in some embodiments, the confidence metric—or more generally, the confidence indicated by the confidence metric—can be inversely related to the distance.

[0064] If, at block 508, the confidence metric satisfies the threshold(s), the method may proceed to block 510, at which point the one or more changes identified at block 506 may be automatically implemented. However, at block 508, if the confidence metric fails to satisfy the threshold(s), then at block 512, the system may generate data that recommends code changes to one or more computing devices, such as those operated by client 110. In some such embodiments, the client may be able to "accept" the changes, for example, by pressing a button on a graphical user interface or by speaking a confirmation. In some embodiments, acceptance of the recommended code changes may be used to further train one or more machine learning models described herein, such as GNN 252 or sequence-to-sequence model 254.

[0065] Figure 6 6 is a flowchart illustrating an example method 600 for training a machine learning model, such as GNN 252, to map a source code snippet to be updated to a latent space containing reference embeddings, according to embodiments disclosed herein. For convenience, the operations of the flowchart are described with reference to a system performing the operations. The system may include various components of various computer systems, such as one or more components of code knowledge system 102. Furthermore, while the operations of method 600 are illustrated in a particular order, this is not intended to be limiting. One or more operations may be reordered, omitted, or added.

[0066] At block 602, the system may obtain data indicating changes between a first version source code snippet and a second version source code snippet. For example, a change graph 228 may be generated, such as by dataset builder 224, based on first version source code snippet 460 and second (or "target") version source code snippet 460'. At block 604, the system may, such as by means of dataset builder 224, generate a change graph 228 of the first version source code snippet 460 and a second (or "target") version source code snippet 460'. Figure 2 The 232) mark in indicates the changed data.

[0067] At block 606, the system can apply the data indicating the change (e.g., change map 228) as input to a machine learning model (e.g., GNN 252) to generate a new embedding in the latent space (e.g., 452). At block 608, the system can determine the distance(s) between the new embedding in the latent space and the previous embedding(s) in the latent space associated with the same and / or different change types. These distances can be calculated using techniques such as cosine similarity, dot product, etc.

[0068] At box 610, the system may calculate an error using the loss function and the distance(s) determined at box 608. For example, if a new embedding with a change of type "change variable name" is closer to the previous embedding(s) of type "change function name" than it was to the previous embedding of type "change variable name", this may mean that the machine learning model that generated the new embedding needs to be updated or trained. Thus, at box 612, the system may train the machine learning model based at least in part on the error calculated at box 610. The training of box 612 may involve techniques such as gradient descent and / or backpropagation. Additionally or alternatively, in various embodiments, other types of labels and / or training techniques may be used to train the machine learning model, such as weak supervision or triplet loss, which may include the use of labels such as similar / dissimilar or close / disclose.

[0069] Figure 7 7 is a block diagram of an example computing device 710 that can optionally be used to perform one or more aspects of the techniques described herein. Computing device 710 typically includes at least one processor 714 that communicates with a number of peripheral devices via a bus subsystem 712. These peripheral devices may include a storage subsystem 724, including, for example, a memory subsystem 725 and a file storage subsystem 726; a user interface output device 720; a user interface input device 722; and a network interface subsystem 716. The input and output devices allow a user to interact with computing device 710. The network interface subsystem 716 provides an interface to an external network and connects to corresponding interface devices in other computing devices.

[0070] The user interface input devices 722 may include a keyboard; a pointing device such as a mouse, trackball, touchpad, or graphics tablet; a scanner; a touch screen incorporated into a display; an audio input device such as a voice recognition system, a microphone, and / or other types of input devices. In general, the use of the term "input device" is intended to include all possible types of devices and ways of inputting information into the computing device 710 or over a communication network.

[0071] The user interface output device 720 may include a display subsystem, a printer, a fax machine, or a non-visual display such as an audio output device. The display subsystem may include a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a projection device, or some other mechanism for creating a visible image. The display subsystem may also provide a non-visual display, such as via an audio output device. In general, the use of the term "output device" is intended to include all possible types of devices and methods for outputting information from the computing device 710 to a user or another machine or computing device.

[0072] The storage subsystem 724 stores programming and data structures that provide the functionality of some or all of the modules described herein. For example, the storage subsystem 724 may include an executable Figure 5-6 Aspects of method selection and implementation Figure 1-2 The logic of the various components is depicted in .

[0073] These software modules are typically executed by processor 714 alone or in combination with other processors. The memory subsystem 725 used in the storage subsystem 724 may include multiple memories, including a main random access memory (RAM) 730 for storing instructions and data during program execution and a read-only memory (ROM) 732 in which fixed instructions are stored. The file storage subsystem 726 may provide persistent storage for program and data files and may include a hard drive, a floppy disk drive and associated removable media, a CD-ROM drive, an optical drive, or a removable media cartridge. Modules that implement the functionality of certain embodiments may be stored by the file storage subsystem 726 in the storage subsystem 724 or in other machines accessible to the processor(s) 714.

[0074] The bus subsystem 712 provides a mechanism for the various components and subsystems of the computing device 710 to communicate with each other as intended. Although the bus subsystem 712 is shown schematically as a single bus, alternative implementations of the bus subsystem may use multiple busses.

[0075] The computing device 710 can be of various types, including a workstation, server, computing cluster, blade server, server farm, or any other data processing system or computing device. Due to the ever-changing nature of computers and networks, Figure 7 The description of computing device 710 depicted in FIG is intended only as a specific example for purposes of illustrating some embodiments. Figure 7 Many other configurations of computing device 710 are possible with more or fewer components than the computing device depicted.

[0076] Although several embodiments have been described and illustrated herein, various other means and / or structures for performing the functions and / or obtaining the results and / or one or more advantages described herein may be utilized, and each such variation and / or modification is considered to be within the scope of the embodiments described herein. More generally, all parameters, dimensions, materials, and configurations described herein are intended to be exemplary and the actual parameters, dimensions, materials, and / or configurations will depend on the specific application or applications in which the teachings are used. Those skilled in the art will recognize or be able to determine, using only routine experimentation, many equivalents to the specific embodiments described herein. Therefore, it should be understood that the foregoing embodiments are presented by way of example only, and that, within the scope of the appended claims and their equivalents, the embodiments may be practiced in a manner other than that specifically described and claimed. Embodiments of the present disclosure relate to each individual feature, system, article, material, kit, and / or method described herein. In addition, any combination of two or more such features, systems, articles, materials, kits, and / or methods, provided that such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent, is included within the scope of the present disclosure.

Claims

1. A method for identifying changes implemented using one or more processors, comprising: applying data associated with the first version of the source code snippet as input to one or more machine learning models to generate new source code embeddings in a latent space; identifying one or more reference embeddings in the latent space based on one or more distances between the one or more reference embeddings in the latent space and the new source code embedding, wherein each of the one or more reference embeddings is generated by applying data indicating changes made to a reference first version source code snippet to produce a reference second version source code snippet as input to one or more of the one or more machine learning models; as well as Based on the identified one or more reference embeddings, one or more changes to be made to the first version of the source code snippet to create a second version of the source code snippet are identified.

2. The method according to claim 1, wherein The data associated with the first version source code snippet includes an abstract syntax tree (AST) generated from the first version source code snippet.

3. The method according to claim 1, wherein One or more of the one or more machine learning models include a graph neural network (GNN).

4. The method according to claim 1, wherein The one or more modifications are identified based on one or more lookup tables associated with the one or more reference embeddings.

5. The method of claim 1 , further comprising generating output to be presented on one or more computing devices, wherein The output, when presented, recommends considering the one or more changes for the first version of the source code snippet. The method of claim 1 , further comprising automatically implementing the one or more changes in the first version source code snippet.

7. The method according to claim 1, wherein The first version source code segment includes a source code file.

8. A method for training a machine learning model implemented using one or more processors, comprising: obtaining data indicating changes between a first version of the source code snippet and a second version of the source code snippet; marking data indicating said change with a change type; applying the data indicative of the changes as input to a machine learning model to generate new embeddings in a latent space; determining a distance in the latent space between the new embedding and a previous embedding in the latent space associated with the same change type; and The machine learning model is trained based at least in part on the distance.

9. The method according to claim 8, wherein The machine learning model includes a graph neural network (GNN).

10. The method according to claim 8, wherein The data indicative of the changes comprises a change map.

11. The method according to claim 10, wherein: The change graph is generated according to a first abstract syntax tree (AST) generated from the first version source code fragment and a second AST generated from the second version source code fragment.

12. The method according to claim 8, wherein The distance includes a first distance, and the method further includes: determining a second distance between the new embedding in the latent space and another previous embedding in the latent space associated with a different change type; and calculating an error based on the first distance and the second distance using a loss function; Wherein, the training is based on the error.

13. The method according to claim 8, wherein The data indicative of the change includes first data indicative of a first change, the new embedding includes a first new embedding, and the method further includes: obtaining second data indicating a second change between the first version source code snippet and the second version source code snippet; marking second data indicating the second change with a second change type; applying second data indicating the second change as input to the machine learning model to generate a second new embedding in the latent space; determining an additional distance between the second new embedding in the latent space and a previous embedding in the latent space associated with the second change type; and The machine learning model is trained based at least in part on the additional distance.

14. A system for identifying modifications, comprising one or more processors and a memory storing instructions, the instructions, in response to execution of the instructions by the one or more processors, causing the one or more processors to: applying data associated with the first version of the source code snippet as input to one or more machine learning models to generate new source code embeddings in a latent space; identifying one or more reference embeddings in the latent space based on one or more distances between the one or more reference embeddings in the latent space and the new source code embedding, wherein each of the one or more reference embeddings is generated by applying data indicating changes made to a reference first version source code snippet to produce a reference second version source code snippet as input on one or more of the one or more machine learning models; as well as Based on the identified one or more reference embeddings, one or more changes to be made to the first version of the source code snippet to create a second version of the source code snippet are identified.

15. The system according to claim 14, wherein: The data associated with the first version source code snippet includes an abstract syntax tree (AST) generated from the first version source code snippet.

16. The system of claim 14, wherein: One or more of the one or more machine learning models include a graph neural network (GNN).

17. The system of claim 14, wherein: The one or more modifications are identified based on one or more lookup tables associated with the one or more reference embeddings.

18. The system of claim 14, further comprising instructions for generating output to be presented on one or more computing devices, wherein The output, when presented, recommends considering the one or more changes for the first version of the source code snippet.

19. The system of claim 14, further comprising instructions for automatically implementing the one or more changes in the first version source code snippet.

20. The system of claim 14, wherein: The first version source code segment includes a source code file.

Images