Learning to Fix Build Errors with Graph2Diff Neural Networks

1 INTRODUCTION

• Build repair is a frequent workflow burden, while professional build errors are often linking or type errors rather than simple syntax errors.Developers build code 7–10 times per day, with a significant number of builds unsuccessful; fixing build errors is described as a potential “sweet spot” for automatic repair because fixes are often short and can be tested by rebuilding.Source: §1 · p. 1
• Professional build repairs often require project API and dependency information, which limits the effectiveness of syntax-focused repair and off-the-shelf neural translation approaches.The related work describes DeepDelta as translating diagnostic text into a repair DSL, with its off-the-shelf NMT system limiting the kinds of errors it can fix effectively.Source: §1 · p. 1
• Graph2Diff maps a graph representation of broken code to a diff using tokens, input-graph pointers, and copy instructions.Graph neural networks encode code structure, pointers select locations to edit, and copying can reuse project-specific identifiers absent from training data.Source: §1 · pp. 1–2
• Graph2Tocopo abstracts graphs, pointers, and copy mechanisms into a framework that is not limited to deep learning or build repair.The authors suggest that the framework may apply to other code-change tasks and that incorporating syntactic and semantic structure benefits deep learning.Source: §1 · p. 2
• 61% precision at producing the exact developer fix when suggesting fixes for 46% of errors; Graph2Diff also achieves over double DeepDelta’s accuracy.The authors also report that some proposed fixes are preferable to the developer’s fix.Source: §1 · p. 2

2 PROBLEM FORMULATION

• The model must predict edit locations as well as repairs because compiler diagnostics do not always identify the code that needs changing.This formulation combines automated fault localization and automated program repair.Source: §2 · p. 2

2.1 Input data format

• Source files are represented as ASTs to capture syntax, and build configuration files are parsed into a similar structure.Source: §2.1 · p. 2
• Compiler diagnostics include a diagnostic kind, associated text, and a filename-and-line location; their text is assumed decomposable into a template and arguments.For example, “Cannot resolve symbol WidgetMaker” can be represented by a template and an argument list containing “WidgetMaker.”Source: §2.1 · p. 2

2.2 Output data format

• The target is a sequence of edits that transforms broken ASTs into fixed ASTs and resolves the diagnostics; this paper restricts fixes to one file and excludes unparseable broken code.GumTree differences between broken and fixed ASTs are converted into insertion, deletion, move, and update operations for the edit script.Source: §2.2 · p. 2

5.2 Output eDSL Design

• The edit-script eDSL represents AST changes as a sequence of operations, including insertions, deletions, moves, and updates.The design aims to make scripts easy to generate from broken and repaired ASTs while fully specifying their changes.Source: §2.2 · p. 2

2.3 Problem Statement

• Given diagnostics, the AST of the file to change, and its associated BUILD-file AST, the model predicts the developer’s edit script.The problem formulation combines localization with repair because diagnostics may not identify the source of the fault.Source: §2.3 · p. 2, §2 · p. 2
• Experiments use a heuristic to select the file with the most diagnostics and evaluate only cases where that first-stage selection is correct, about 90% of the data.The authors state that incorrect first-stage predictions should count as errors in deployment.Source: §2.3 · p. 2

3.1 Build Repair Dataset

• The dataset contains roughly 500,000 fixes collected from one year of successive builds, where the first build had compiler diagnostics and the next had none.The collected snapshots capture code before and after developer repairs.Source: §3.1 · p. 3, §3 · p. 3
• Dataset construction keeps fixes of at most seven edit operations that parse and change Java code in the file with the most diagnostics.It excludes fixes limited to build configuration, command-line flags, or unexpected files, while leaving diagnostic kinds, edit-script vocabulary, and input-file sizes unrestricted.Source: §3.1 · p. 3
• The same diagnostic kind can require different replacement patterns, and diagnostic kinds have a heavy-tailed frequency distribution.The authors use this variation to motivate source-code context and a learning-based approach rather than hand-crafted tools for individual diagnostics.Source: §3.1 · p. 3
• Some fixes require longer edit scripts: one example takes four operations, while a variable-misuse repair takes one.The paper reports the overall edit-script-length distribution in Figure 2(a).Source: §3.1 · p. 3
• 36% of cases require changing a line not indicated by a diagnostic, and approximately 25% of failures have multiple diagnostics.The examples include cases where the diagnostic names another identifier or points to a different line than the one needing repair.Source: §3.1 · p. 3
• 21% of the data requires edits to more than one contiguous region, with different changes needed at different locations.The authors note that these fixes are not necessarily independent changes or repetitions of the same change.Source: §3.1 · p. 3

4 GRAPH2TOCOPO ABSTRACTION

• Graph2Tocopo provides an interface for code-editing tasks, with tool developers designing graph inputs and edit-specific eDSLs while model developers choose learning methods.The abstraction is not specific to deep learning.Source: §4 · p. 3

4.1 Code as Graphs

• A code graph can combine AST structure with information such as errors or program analyses, using labeled nodes and edges to relate these sources.Nodes have a type and string value; edges are typed and directed.Source: §4.1 · pp. 3–4

4.2 Edits as Tocopo Sequences

• A Tocopo sequence combines literal tokens, copies of input-node values, input-node pointers, and pointers to earlier output elements.Pointers identify locations, while copies refer to node values; output pointers can express relationships among newly generated elements.Source: §4.2 · pp. 4–5

4.3 Program Repair as Graph2Tocopo

• Variable-misuse repair can be represented as selecting a candidate node with an input pointer, or as pointing to the erroneous use and copying a correct replacement value.The examples map prior repair methods into Graph2Tocopo sequences.Source: §4.3 · p. 5

4.4 Learning for Graph2Tocopo

• Training can maximize probability over all reference-equivalent Tocopo sequences, so the model need not reproduce one particular sequence for an edit.The paper says this objective can often be computed efficiently, and that Graph2Diff models constrain it to make computation inexpensive.Source: §4.4 · p. 5

5 BUILD REPAIR AS GRAPH2TOCOPO

• The build-repair input graph includes source-code, compiler-diagnostic, and build-file subgraphs.The source code and build file are represented as trees, while each diagnostic subgraph contains its kind, message tokens, arguments, and a root.Source: §5.1 · p. 5

5.1 Input Graph Representation

• Typed edges connect AST parents and children, traversal neighbors, repeated lexical uses, diagnostic roots to code on the reported line, and diagnostic arguments to matching code nodes.The authors note that an ablation removing all edges shows their importance.Source: §5.1 · pp. 5–6

5.2 Output eDSL Design

• The edit-script eDSL transforms the broken AST through insertions, deletions, updates, and moves, with DONE marking the sequence's end.Insertion specifies a parent and previous sibling; the example constructs a three-node subtree and deletes the old type.Source: §5.2 · p. 6

6 GRAPH2DIFF ARCHITECTURE

• Graph2Diff uses a graph encoder to produce node states and an edit-script decoder to predict successive Tocopo expressions from those states and prior predictions.The decoder is based on the Transformer architecture, with custom modifications for Tocopo features.Source: §6 · p. 6

6.1 Graph Encoder

• The GGNN encoder initializes node representations from node type, value, and traversal position, then updates them through repeated neighbor-information propagation.The number of propagation steps is fixed for each model.Source: §6.1 · p. 6

6.2 Edit-Script Decoder

• The decoder alternates causal self-attention over the partial edit script with output-input attention from graph nodes, then predicts the next expression.Its output layer combines token, copy, and pointer scores into one prediction distribution.Source: §6.2 · pp. 6–7
• In the current implementation, output pointers are simplified: the model predicts where they occur but not what they point to.The discussion therefore treats OUTPUT_POINTER as a vocabulary item.Source: §6.2 · p. 6
• To keep future predictions consistent across reference-equivalent prefixes, the decoder represents each prior expression as a set of equivalent Tocopo expressions.This constraint supports efficient training under the stated objective.Source: §6.2 · p. 7

7.1.1 Experimental details.

• Sequence-level accuracy requires an exact full-sequence match to the developer's change; the evaluation uses train, validation, and test splits with grid search for hyperparameters.The authors note that future work would measure whether developers find proposed fixes useful.Source: §7.1.1 · p. 7

7.1.2 Effect of context size and model depth.

• Including more graph context and performing more propagation steps generally improve performance, though pruning can remove needed edit locations, copy targets, or useful context.The pruning trade-off reflects the risk of losing code locations or vocabulary needed to produce the correct fix.Source: §7.1.2 · p. 7, Figure 5 · p. 8

7.1.3 Effect of dataset size.

• Increasing the training-set size improves validation accuracy, as shown by the right side of Figure 5.The figure plots best validation accuracy against training-set size on a log-scale x-axis.Source: §7.1.3 · p. 7, Figure 5 · p. 8

7.2 RQ2: Comparison to Sequence2Sequence

• 26% test accuracy for Graph2Diff versus 10% for DeepDelta, although Graph2Diff predicts more precise changes.The comparison uses the best-validation-accuracy models; less precise output formats generally yield higher accuracy but can overestimate practical performance.Source: §7.2 · pp. 8–9, Figure 6 · p. 9

7.3 RQ3: How often do incorrect fixes build?

• 61% exact-fix precision when suggesting repairs for 46% of dataset errors, estimated after build-testing sampled incorrect predictions.Of 50 sampled incorrect examples, 13 (26%) built successfully.Source: §7.3 · p. 9

7.4.1 Example Correct and Incorrect Fixes.

• For incompatible-type diagnostics, correct predictions include adding method calls, copying a rare type token, and converting an integer literal to a long literal; errors include mishandling rare method signatures.The examples are limited to one diagnostic kind, chosen to illustrate varied fix patterns.Source: §7.4.1 · p. 9

7.4.2 Accuracy by Diagnostic Kind.

• The model fixes many diagnostic kinds, but never correctly fixes a missing-return-statement error, which the authors suspect requires synthesis under contextual type constraints.Figure 8 reports accuracy for kinds occurring at least 10 times in validation data.Source: §7.4.2 · p. 9

7.4.3 Incorrect Fixes that Build Successfully.

• Some buildable predictions differ from developer fixes in useful ways, including replacing a deprecated import, while another example is a semantically different false positive.The authors also describe a prediction that changes a method name differently from the ground truth.Source: §7.4.3 · p. 9

8 RELATED WORK

• Li et al. [19] predict graph-node pointers, while Graph2Diff adds copy, output feedback, and weak supervision; Xu et al. [42] and Beck et al. [7] lack copy and pointer mechanisms.Song et al. [33] include copying but not an equivalent pointer mechanism.Source: §8 · p. 9
• Unlike SequenceR [11], which uses external fault localization to predict a fixed line, Graph2Diff can learn to edit anywhere in a graph-structured input.SequenceR uses failing tests and a copy-enabled sequence model with local code context.Source: §8 · p. 10
• Variable-misuse methods differ in localization: Allamanis et al. [3] rely on an external enumerative strategy, whereas Vasic et al. [35] use two output pointers.The first pointer localizes the error and the second identifies a replacement variable; the first prediction is not fed back into the second.Source: §8 · p. 10
• DeepFix and TRACER differ from Graph2Diff in localization, input scope, and handling multiple edits; Graph2Diff uses the whole program and predicts fixes simultaneously.Graph2Diff copies project identifiers rather than renaming variables and does not assume multi-line bugs are independent.Source: §8 · p. 10
• DeepDelta is the closest build-repair work, while Graph2Diff addresses more error types and its post-filtering yields higher precision.DeepDelta translates diagnostic text into a repair description in a custom DSL; the paper reports similar results on more error types.Source: §8 · p. 10

9 DISCUSSION

• The end-to-end approach more than doubles prior work’s accuracy and learns to fix a wide variety of errors in professional developers’ day-to-day data.The evaluation uses a large dataset of errors encountered in that setting.Source: §9 · p. 10
• Graph2Tocopo lets tool developers add task-relevant information to input graphs and define higher-level edit actions through task-specific DSLs.The framework generalizes several recent works [3] [11] [35] and was used with different input and output design choices in the paper’s experiments.Source: §9 · p. 11
• The authors present build-error repair as a potential stepping stone to software-maintenance tasks that require larger code changes.Source: §9 · p. 11

A.1 Background Ops

• Sparse attention aggregates information from allowed source entities, while graph propagation sends edge-specific messages and updates each node with a GRU.Causal self-attention is a special case that lets each output step attend only to itself and earlier steps.Source: §A.1 · p. 12

A.2 Accommodating Weak Supervision

• For weak supervision, reference-equivalent Tocopo expressions form per-timestep sets, and conditioning on those sets enables linear-time rather than exponential-time marginalization.The decoder feeds back the equivalence sets rather than the particular expressions used to generate them.Source: §A.2 · pp. 12–13
• A simpler decoder with conditionally independent timestep predictions cannot represent some coupled output distributions and performs significantly worse on this task.One example is assigning probability to either change A at position X or change B at position Y.Source: §A.2 · p. 13

A.3 Tocopo Decoder

• The decoder propagates information between output steps and from the input graph; causal self-attention prevents future outputs from influencing earlier predictions.Output step t’s final hidden state depends on the input graph and outputs through t.Source: §A.3 · p. 13
• Previous output embeddings combine token, copy, and pointer information, using graph nodes as the sources for copy and pointer embeddings.Copy information may draw on multiple eligible nodes, while each output sequence has at most one pointer target.Source: §A.3 · p. 13
• Three output heads predict tokens, copies, or pointers, producing a distribution over vocabulary items and input-graph nodes.The token head predicts vocabulary logits; copy and pointer heads each produce logits over graph nodes.Source: §A.3 · p. 14

B FORMAL SEMANTICS OF TOCOPO SEQUENCES

• Tocopo sequences are equivalent when dereferencing their pointers and copy operations yields equal semantics, a notion intended to generalize across edit DSLs.Dereferencing resolves references while otherwise leaving the sequence essentially unchanged.Source: B FORMAL SEMANTICS OF TOCOPO SEQUENCES · p. 14

C.1 Experimental details

• Resolutions were randomly split into 80% training, 2,500 validation examples, and 10% test, with hyperparameters selected by grid search.Source: §C.1 · p. 14
• The reported model uses the training step and configuration with the best validation accuracy; larger runs took about one week on a single GPU.Training was allowed up to 1M updates.Source: §C.1 · p. 14

C.2 Effect of autoregressive feedback

• Removing autoregressive feedback costs 5–6% absolute performance, or 20–26% relative degradation.The ablation generates sequences without feeding previous outputs back to the model.Source: §C.2 · p. 14

• The ablation linearized diagnostic, build, and Java subgraphs by depth-first preorder, removed input edges, then added links within distance 10 in the ordering.The setup was intended to mimic Transformer-style local attention over linearized trees [25] [39].Source: §C.2.1 · p. 14
• No hyperparameter setting achieved more than 3% sequence-level validation accuracy, and the best-performing edge-ablated model used pruning at diameter 1 with 12 propagation steps.The authors speculate that edge ablation loses information critical for localizing edits; diameter 1 suffers least because it extracts the subgraph around errors, easing localization at the cost of solving fewer problems from local context.Source: §C.2.1 · p. 14
• Figure 10 examines the effect of removing autoregressive feedback in the decoder.Source: Figure 10 · p. 15