Pith. sign in

REVIEW 4 major objections 6 minor 57 references

Call Me Maybe: Enhancing JavaScript Call Graph Construction using Graph Neural Networks

T0 review · 4 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A GNN can rank the correct callee for unresolved JavaScript call sites, reaching top-5 accuracy in 72% of cases.

desk verdict A useful new application of GNN link prediction to whole-program graphs, but the headline numbers are about reproducing CodeQL; the evidence for finding genuinely missed edges is thinner and needs stronger evaluation. read the letter →

arxiv 2506.18191 v1 pith:UFMZPQOG submitted 2025-06-22 cs.SE cs.AIcs.LG

Masudul Hasan Masud Bhuiyan , Gianluca De Stefano , Giancarlo Pellegrino , Cristian-Alexandru Staicu This is my paper · ORCID
classification cs.SEcs.AIcs.LG
keywords callgraphconstructionJavaScriptstaticanalysisneuralnetworkslinkpredictionprogramgraphsdynamicedgesrecallsemantic
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Static call graph tools for JavaScript leave many call sites unresolved because dynamic property access, higher-order functions, and cross-file definitions defeat purely static analysis. This paper claims that a graph neural network can take over those unresolved call sites: if the whole program is represented as a graph, link prediction can rank the correct callee among every function definition in the project. GRAPHIA ranks the right target first in over 42% of unresolved cases and within the top five in 72%, so an analyst could check a short list instead of searching the entire codebase. It also shows the model can learn from static edges alone or from a mix of static and dynamic edges, including dynamic edges gathered from other projects. Reducing false negatives in call graph construction matters because missing edges hide security-relevant flows from downstream interprocedural analyses.

What carries the argument

The load-bearing object is the augmented program graph: a pruned abstract syntax tree whose nodes are connected by structural edges and by semantic edges that link every occurrence of the same identifier to a dedicated semantic node. These semantic edges shorten the path between a call site and a far-away callee, letting a graph neural network with gated message passing propagate information across file boundaries and long-distance relations. Node features are the AST node type, identifier name, and argument or parameter counts. The same graph carries the training signal as call-edge labels, so link prediction on this representation is what turns code structure into candidate rankings.

What would settle it

Manually resolve a random sample of statically unresolved call sites in the ten tested libraries by full runtime tracing or code inspection, then rerun GRAPHIA's ranking against that ground truth; if top-5 accuracy on that sample falls well below 72%, the novel-edge claim is an artifact of test coverage.

Watch

Extended reading notes

Core claim

The paper's central claim is that JavaScript call graph completion can be framed as link prediction over the entire program, and that a graph neural network can handle a meaningful share of that task. GRAPHIA builds a whole-program graph from a pruned abstract syntax tree, adds semantic nodes connected to every use of the same identifier, and labels call edges with static edges from existing analysis tools plus dynamic edges from instrumented unit tests. At inference time, each statically unresolved call site is scored against all candidate function definitions, and the output is a ranked list rather than a binary edge decision. On 50 npm libraries with 163K call edges, the correct callee is the top-ranked candidate in more than 42% of unresolved cases and appears in the top five in 72%. The authors take these numbers as evidence that learning-based link prediction can complement existing static call graph tools by reducing their false negatives.

Load-bearing premise

The load-bearing premise is that the edges recovered by running each library's unit tests are a fair and representative sample of the edges that static analysis misses; if the tests cover only easy call patterns, the measured novel-edge rankings overstate how often GRAPHIA would resolve real-world unresolved call sites.

Editorial extensions

If this is right

  • Static call graph tools can be augmented without retraining from scratch: GRAPHIA learns from the tool's own static edges and then proposes candidates for the call sites the tool leaves open.
  • Analysts would inspect a ranked shortlist of possible callees for each unresolved call site instead of the whole project, with top-5 accuracy of 72% bounding the manual effort.
  • Dynamic edges gathered from unit tests of one set of libraries transfer to others: transfer experiments improved rank-0 accuracy for mathjs, formula-parser, express, and js-yaml by 18% to 92%.
  • The proposed code representation carries most of the performance: removing the syntactic and semantic structure drops rank-0 accuracy by 61% for formula-parser and by large margins for several other libraries.
  • The paper's own discussion points toward a human-in-the-loop pipeline in which analysts vet the top-ranked candidates, especially because graph neural network outputs are hard to explain.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural testable extension is to plug the top-k candidate edges into a downstream taint or alias analysis and measure how many new security findings appear; the current paper stops at edge rankings, so the end-to-end payoff is not yet measured.
  • The same whole-program link prediction recipe could transfer to Python, Ruby, or PHP, where dynamic dispatch and higher-order functions create similar unresolved-call problems, though the semantic-edge design would need to adapt to each language's scoping rules.
  • If the ranking signal relies heavily on identifier names, minified or renamed production code may degrade accuracy; an explicit test would compare GRAPHIA's ranks on a library before and after minification.
  • Semantic edges act as a learned substitute for pointer analysis: instead of computing points-to sets, the model short-circuits name and structure relations, so the approach's ceiling likely depends on how often those shortcuts are sufficient.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. GRAPHIA is a GNN-based link prediction approach that builds a whole-program graph from a pruned AST augmented with semantic identifier nodes, and trains on static call edges from CodeQL, optionally combined with dynamic edges from instrumented unit tests. For each call site, GRAPHIA ranks all candidate function definitions in the project; the paper claims that it places the correct callee first in over 42% and within the top five in 72% of statically unresolved call sites, thereby augmenting JavaScript call graph construction. The evaluation covers 50 npm libraries, four research questions, two ablations, a transfer-learning study, and is accompanied by a replication package.

Significance. If the central claim were properly supported, this would be a useful new ML-based augmentation path for JavaScript call graph analysis, and the paper's large-scale dataset, ranking-based evaluation, ablations, and publicly released replication package are genuine strengths. The focus on ranking rather than ROC is well motivated, and the idea of learning from imperfect static and dynamic labels is worth pursuing. However, the current evidence does not establish the headline capability: the main quantitative claims are computed on static edges that the baseline tool already resolved, and the only experiment on truly unresolved edges lacks a baseline and coverage control. The paper is therefore promising but requires substantial revision before its central claim can be accepted.

major comments (4)
  1. [IV-C and Abstract/Introduction] Section IV-C states that the RQ1 test set 'exclusively comprises call edges derived from the output of the static analysis tool,' meaning the test edges are exactly the edges CodeQL resolved; ranking them among all candidate function definitions measures retrieval fidelity to CodeQL, not recovery of missed call edges. The abstract's claim that 'for more than 42% of the statically-unresolved call sites, GRAPHIA correctly predicts the right target function' is therefore not supported by RQ1, and the introduction uses the same numbers for 'unresolved cases.' The only experiment targeting genuinely unresolved call sites is RQ2, and its limitations are discussed separately.
  2. [IV-D] RQ2 selects 'ten large npm libraries with substantial test coverage' but reports no coverage metric, and the authors concede that unit tests 'might not execute the entire program functionality.' The experiment evaluates only ten libraries without a baseline such as name-based or lexical matching, and without statistical significance tests. As a result, the dynamic ground truth may be biased toward easy, test-covered patterns, so the reported rank accuracy (e.g., 68% for express) does not establish the rate at which GRAPHIA would resolve real-world unresolved call sites.
  3. [III-D / IV-C] In Section III-D, the dataset is split into 80/10/10 subsets at the level of individual call edges, and the GNN is trained and tested on the same whole-program graph. Under this transductive, edge-level split, test edges share call-site nodes with training edges, so the model has already observed each test call site's local and global context during training. This can inflate the ranking metrics in RQ1; the paper should split by call sites or by files, or report the results under such a split.
  4. [I and IV-F] The paper frames the contribution as improving the recall of JavaScript call graph construction, but it never measures the end-to-end effect on a call graph, e.g., how many true edges are added and how many false positives are introduced when the top-k candidates are accepted for unresolved call sites. The ranking metric alone, even where valid, does not quantify recall improvement; an experiment that augments CodeQL's output with GRAPHIA's top-k predictions and compares precision/recall against a non-learning baseline would make the practical claim testable.
minor comments (6)
  1. [Abstract] Replace 'statically-unresolved call sites' with 'held-out static edges' in the sentence reporting the 42%/72% results, because those results come from RQ1.
  2. [IV-E] The formal definition 'Ri = Rank(P i)' does not define a position in a ranked list; please formalize the ranking computation, including the treatment of ties and the candidate space for each call site.
  3. [III-D] Clarify the learning-rate schedule and whether the batch size of 32,768 counts training edges, graph nodes, or call-site–candidate pairs.
  4. [IV-G] RQ5 is a case study on the express package only; the text should state this explicitly rather than generalizing to GRAPHIA's overall versatility.
  5. [Figure 6] Add a legend or otherwise identify which curve belongs to each package; without it, the claimed variance across libraries cannot be inspected.
  6. [IV-C] Specify the exact weighting formula for the aggregate statistics (e.g., weight by number of call edges) so the reader can reproduce the weighted averages.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the dynamic-edge evaluation (RQ2) is independent of the static training labels, and no central claim reduces by construction to its own inputs.

full rationale

The central training signal is CodeQL static edges, and the main generalization test for missed edges is RQ2, where the model is 'trained the model exclusively with static call edges, consistent with the setup in IV-C, and assessed the rank of each edge relative to other potential candidates' against dynamically extracted edges. Those dynamic test labels were not used to fit the RQ2 model, so the reported ranking performance is not forced by construction. RQ1 is explicitly framed as approximating CodeQL: its test set 'exclusively comprises call edges derived from the output of the static analysis tool,' which is a held-out fidelity measurement, not a fitted-input-as-prediction loop. The abstract's wording that the 42%/72% figures apply to 'statically-unresolved call sites' is inconsistent with the Section IV-C definition of the test set, but that is an overclaim about the target quantity, not a circular reduction: the model parameters are not defined in terms of the test edges. The only cited prior work is external (CodeQL, Babel, DGL, GatedGCN, cGPruner, AutoPruner), and no load-bearing argument is justified by a self-citation. The paper's own limitation that unit tests 'might not execute the entire program functionality' concerns the representativeness of the dynamic ground truth, which is an external validity threat rather than circularity. Overall, the derivation chain is self-contained: training labels, held-out test labels, and dynamic evaluation labels are distinct and are not used to define each other.

Assumptions & free parameters 4 free parameters · 4 assumptions · 1 invented entities

The central empirical claims depend on the quality of the ground truth from CodeQL and dynamic instrumentation, on the graph construction heuristics, and on the evaluation split. The paper does not justify that random edge splits in a transductive GNN avoid information leakage.

free parameters (4)
  • GNN hyperparameters (5 layers, max 500 epochs, batch size 32768)
    Chosen without systematic tuning; performance numbers depend on them but they are not fitted to evaluation data.
  • AST pruning criteria
    Node types to remove are hand-selected to reduce graph size; no principled derivation is provided (Section III-A).
  • Node feature set (node type, name, #params, #args)
    Selected based on prior work (Utture et al.); not ablated individually beyond a null-feature comparison.
  • Dataset inclusion threshold (>=250 non-built-in call edges) = 250 call edges
    Chosen to ensure enough training signal per package; affects which libraries are in the study.
assumptions (4)
  • domain assumption CodeQL static call edges used as training labels are mostly true positives
    The training set treats CodeQL output as approximate ground truth; if CodeQL contains systematic false positives, the model learns them (Section III-C and IV-H).
  • domain assumption Dynamically instrumented unit test executions produce true call edges
    Used as test ground truth for RQ2 and as additional training data; coverage of the whole library is not quantified (Section IV-D).
  • domain assumption Random split of edges yields independent training and test sets in a transductive graph
    Because the GNN message passing runs on the whole program graph, nodes from test edges are visible during training unless explicitly masked; the paper does not describe edge masking (Section III-D).
  • ad hoc to paper Connecting identifiers with the same name via semantic nodes aids learning real call relations
    Name-based linking is a heuristic; the ablation shows it helps on this dataset, but it is not justified by a formal semantic argument (Section III-B).
invented entities (1)
  • Semantic identifier nodes
    purpose: Additional graph nodes representing each distinct identifier, connected to all AST usages of that identifier to shorten message-passing paths and capture name-level aliasing.
    Internal ablation shows removal degrades performance, but there is no external or semantic grounding for why name-based linking should correspond to true call relations.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Call Me Maybe: Enhancing JavaScript Call Graph Construction using Graph Neural Networks." pith.science (2026). https://pith.science/paper/UFMZPQOG

@misc{pith2026250618191,
  author       = {Pith},
  title        = {Pith review of: Call Me Maybe: Enhancing JavaScript Call Graph Construction using Graph Neural Networks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UFMZPQOG}},
  note         = {Machine review of arXiv:2506.18191}
}
read the original abstract

Static analysis plays a key role in finding bugs, including security issues. A critical step in static analysis is building accurate call graphs that model function calls in a program. However, due to hard-to-analyze language features, existing call graph construction algorithms for JavaScript are neither sound nor complete. Prior work shows that even advanced solutions produce false edges and miss valid ones. In this work, we assist these tools by identifying missed call edges. Our main idea is to frame the problem as link prediction on full program graphs, using a rich representation with multiple edge types. Our approach, GRAPHIA, leverages recent advances in graph neural networks to model non-local relationships between code elements. Concretely, we propose representing JavaScript programs using a combination of syntactic- and semantic-based edges. GRAPHIA can learn from imperfect labels, including static call edges from existing tools and dynamic edges from tests, either from the same or different projects. Because call graphs are sparse, standard machine learning metrics like ROC are not suitable. Instead, we evaluate GRAPHIA by ranking function definitions for each unresolved call site. We conduct a large-scale evaluation on 50 popular JavaScript libraries with 163K call edges (150K static and 13K dynamic). GRAPHIA builds program graphs with 6.6M structural and 386K semantic edges. It ranks the correct target as the top candidate in over 42% of unresolved cases and within the top 5 in 72% of cases, reducing the manual effort needed for analysis. Our results show that learning-based methods can improve the recall of JavaScript call graph construction. To our knowledge, this is the first work to apply GNN-based link prediction to full multi-file program graphs for interprocedural analysis.

Figures

Figures reproduced from arXiv: 2506.18191 by the authors.

Figure 1
Figure 1. Caller function code snippet from formula-parser JavaScript library 1 var lexer = function (){ 2 var lexer = ({ 3 showPosition: function () { 4 var pre = this.pastInput(); 5 var c = new Array(pre.length + 1).join("-"); 6 return pre + this.upcomingInput() + "\n" + c + "ˆ"; 7 } 8 }); 9 return lexer; 10 })(); 11 parser.lexer = lexer; [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. is attached to a named property of a local object lit￾eral. This object is then returned from an immediately invoked function and assigned to a lexer property of a parser object. In line 1 of [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Combined code representation containing both syn [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: The overview of GRAPHIA framework. and comprehensive understanding of complex relationships within the code base. III. METHODOLOGY [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: Performance of two models with similar ROC curves, [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 8
Figure 8. Figure 8: Distribution of GRAPHIA’s Performance in Predicting Statically-Unknown Edges - We train the model with static ground truth, but evaluate it with dynamically-extracted ones. In the case of the express and UglifyJS libraries, GRAPHIA successfully predicts true edges in 6…
Figure 6
Figure 6. Figure 6: Distribution of Edge Prediction Ranking in G [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: Confidence Score of Candidate Edges in express - Each point on the x-axis is an individual call site, for which we plot the highest ten predictions. The true edges are depicted by orange circles, and other candidates by blue crosses. formula- parser lodash js-yaml expr…
Figure 9
Figure 9. Figure 9: Performance Comparison: GRAPHIA with Call Nodes (Graphiashort) vs. Original Design (Graphiaorg) (a), and Performance Analysis: GRAPHIA with Null Features (Graphiarand) vs. Original Design (Graphiaorg) (b). critical role of both syntactic and semantic nodes and edges in…
Figure 11
Figure 11. Figure 11: Impact of Transfer Learning on GRAPHIA’s Perfor￾mance. The blue bars represent models trained solely with static ground truth, while the green bars depict models trained with dynamically-extracted edges. Additionally, the orange bars signify models trained with data f…

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

57 extracted references · 41 canonical work pages

  1. [1]

    An interprocedural data flow analysis algorithm,

    J. M. Barth, “An interprocedural data flow analysis algorithm,” inPro- ceedings of the 4th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages, pp. 119–131, 1977

    work page 1977

  2. [2]

    Gprof: A call graph execution profiler,

    S. L. Graham, P. B. Kessler, and M. K. McKusick, “Gprof: A call graph execution profiler,”ACM Sigplan Notices, vol. 17, no. 6, pp. 120–126, 1982

    work page 1982

  3. [3]

    Classes of recursively enumerable sets and their decision problems,

    H. G. Rice, “Classes of recursively enumerable sets and their decision problems,”Transactions of the American Mathematical society, vol. 74, no. 2, pp. 358–366, 1953

    1953

  4. [4]

    Wala download — sourceforge.net

    “Wala download — sourceforge.net.” https://sourceforge.net/projects/ wala/

    work page

  5. [5]

    Is javascript call graph extraction solved yet? a comparative study of static and dynamic tools,

    G. Antal, P. Heged ˝us, Z. Herczeg, G. L ´oki, and R. Ferenc, “Is javascript call graph extraction solved yet? a comparative study of static and dynamic tools,”IEEE Access, vol. 11, pp. 25266–25284, 2023

    work page 2023

  6. [6]

    Striking a balance: pruning false-positives from static call graphs,

    A. Utture, S. Liu, C. G. Kalhauge, and J. Palsberg, “Striking a balance: pruning false-positives from static call graphs,” inProceedings of the 44th International Conference on Software Engineering, pp. 2043–2055, 2022

    work page 2022

  7. [7]

    Strictly declarative specification of sophisticated points-to analyses,

    M. Bravenboer and Y . Smaragdakis, “Strictly declarative specification of sophisticated points-to analyses,” inProceedings of the 24th ACM SIG- PLAN conference on Object oriented programming systems languages and applications, pp. 243–262, 2009

    work page 2009

  8. [8]

    A user-guided approach to program analysis,

    R. Mangal, X. Zhang, A. V . Nori, and M. Naik, “A user-guided approach to program analysis,” inProceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, pp. 462–473, 2015

    work page 2015

Show all 57 references
  1. [9]

    Making k-object-sensitive pointer analysis more precise with still k-limiting,

    T. Tan, Y . Li, and J. Xue, “Making k-object-sensitive pointer analysis more precise with still k-limiting,” inStatic Analysis: 23rd International Symposium, SAS 2016, Edinburgh, UK, September 8-10, 2016, Proceed- ings, pp. 489–510, Springer, 2016

    2016

  2. [10]

    Autopruner: transformer-based call graph pruning,

    T. Le-Cong, H. J. Kang, T. G. Nguyen, S. A. Haryono, D. Lo, X.- B. D. Le, and Q. T. Huynh, “Autopruner: transformer-based call graph pruning,” inProceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering,...

    2022

  3. [11]

    Static JavaScript call graphs: A comparative study,

    G. Antal, P. Hegedus, Z. T ´oth, R. Ferenc, and T. Gyim ´othy, “Static JavaScript call graphs: A comparative study,” in2018 IEEE 18th Interna- tional Working Conference on Source Code Analysis and Manipulation (SCAM), pp. 177–186, IEEE, 2018

    2018

  4. [12]

    Au- tomatic root cause quantification for missing edges in javascript call graphs (extended version),

    M. Chakraborty, R. Olivares, M. Sridharan, and B. Hassanshahi, “Au- tomatic root cause quantification for missing edges in javascript call graphs (extended version),”arXiv preprint arXiv:2205.06780, 2022

    2022 arXiv

  5. [13]

    code2vec: learning distributed representations of code,

    U. Alon, M. Zilberstein, O. Levy, and E. Yahav, “code2vec: learning distributed representations of code,”Proceedings of the ACM on Pro- gramming Languages, vol. 3, pp. 1 – 29, 2018

    2018

  6. [14]

    Structured generative models of natural source code,

    C. J. Maddison and D. Tarlow, “Structured generative models of natural source code,”ArXiv, vol. abs/1401.0514, 2014

    2014 arXiv

  7. [15]

    A novel neural source code representation based on abstract syntax tree,

    J. Zhang, X. Wang, H. Zhang, H. Sun, K. Wang, and X. Liu, “A novel neural source code representation based on abstract syntax tree,” 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE), pp. 783–794, 2019

    2019

  8. [16]

    Learning to repre- sent programs with graphs,

    M. Allamanis, M. Brockschmidt, and M. Khademi, “Learning to repre- sent programs with graphs,”ArXiv, vol. abs/1711.00740, 2017

    2017 arXiv

  9. [17]

    Neural code com- prehension: A learnable representation of code semantics,

    T. Ben-Nun, A. S. Jakobovits, and T. Hoefler, “Neural code com- prehension: A learnable representation of code semantics,”ArXiv, vol. abs/1806.07336, 2018

    2018 arXiv

  10. [18]

    Vuldeepecker: A deep learning-based system for vulnerability detec- tion,

    Z. Li, D. Zou, S. Xu, X. Ou, H. Jin, S. Wang, Z. Deng, and Y . Zhong, “Vuldeepecker: A deep learning-based system for vulnerability detec- tion,”ArXiv, vol. abs/1801.01681, 2018

    2018 arXiv

  11. [19]

    Deepsim: deep learning code functional simi- larity,

    G. Zhao and J. Huang, “Deepsim: deep learning code functional simi- larity,”Proceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2018

    2018

  12. [20]

    Devign: Effective vulner- ability identification by learning comprehensive program semantics via graph neural networks,

    Y . Zhou, S. Liu, J. Siow, X. Du, and Y . Liu, “Devign: Effective vulner- ability identification by learning comprehensive program semantics via graph neural networks,”ArXiv, vol. abs/1909.03496, 2019

    1909 arXiv

  13. [21]

    Tree-to-tree neural networks for program translation,

    X. Chen, C. Liu, and D. Song, “Tree-to-tree neural networks for program translation,”Advances in neural information processing systems, vol. 31, 2018

    2018

  14. [22]

    Flow2vec: Value-flow-based precise code embedding,

    Y . Sui, X. Cheng, G. Zhang, and H. Wang, “Flow2vec: Value-flow-based precise code embedding,”Proceedings of the ACM on Programming Languages, vol. 4, no. OOPSLA, pp. 1–27, 2020

    2020

  15. [23]

    Link prediction based on graph neural networks,

    M. Zhang and Y . Chen, “Link prediction based on graph neural networks,” inAdvances in Neural Information Processing Systems 31: Annual Conference on Neural Information Processing Systems 2018, NeurIPS 2018, December 3-8, 2018, Montr ´eal, Canada, pp. 5171–5181, 2018

    2018

  16. [24]

    GitHub, “Codeql,” 2022

    2022

  17. [26]

    Deep graph library: A graph-centric, highly-performant package for graph neural networks,

    M. Wang, D. Zheng, Z. Ye, Q. Gan, M. Li, X. Song, J. Zhou, C. Ma, L. Yu, Y . Gai, T. Xiao, T. He, G. Karypis, J. Li, and Z. Zhang, “Deep graph library: A graph-centric, highly-performant package for graph neural networks,”arXiv preprint arXiv:1909.01315, 2019

    1909 arXiv

  18. [27]

    Pytorch,

    S. Imambi, K. B. Prakash, and G. Kanagachidambaresan, “Pytorch,” Programming with TensorFlow: Solution for Edge Computing Applica- tions, pp. 87–104, 2021

    2021

  19. [28]

    Benchmarking graph neural networks,

    V . P. Dwivedi, C. K. Joshi, A. T. Luu, T. Laurent, Y . Bengio, and X. Bresson, “Benchmarking graph neural networks,” 2022

    2022

  20. [29]

    npm rank

    “npm rank.” https://gist.github.com/anvaka/8e8fa57c7ee1350e3491

  21. [30]

    Aletheia: Improving the usability of static security analysis,

    O. Tripp, S. Guarnieri, M. Pistoia, and A. Aravkin, “Aletheia: Improving the usability of static security analysis,” inProceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, pp. 762–774, 2014

    2014

  22. [31]

    Prioritizing alerts from multiple static analysis tools, using classification models,

    L. Flynn, W. Snavely, D. Svoboda, N. VanHoudnos, R. Qin, J. Burns, D. Zubrow, R. Stoddard, and G. Marce-Santurio, “Prioritizing alerts from multiple static analysis tools, using classification models,” in Proceedings of the 1st international workshop on software qualities and ...

    2018

  23. [32]

    On the effectiveness of machine learning-based call graph pruning: An empirical study,

    A. M. Mir, M. Keshani, and S. Proksch, “On the effectiveness of machine learning-based call graph pruning: An empirical study,” 2024

    2024

  24. [33]

    Typilus: Neural type hints,

    M. Allamanis, E. T. Barr, S. Ducousso, and Z. Gao, “Typilus: Neural type hints,” inProceedings of the 41st acm sigplan conference on programming language design and implementation, pp. 91–105, 2020

    2020

  25. [34]

    Typewriter: Neural type prediction with search-based validation,

    M. Pradel, G. Gousios, J. Liu, and S. Chandra, “Typewriter: Neural type prediction with search-based validation,” inProceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, pp. 209–220, 2020

    2020

  26. [35]

    Deep learning type inference,

    V . J. Hellendoorn, C. Bird, E. T. Barr, and M. Allamanis, “Deep learning type inference,” inProceedings of the 2018 26th acm joint meeting on european software engineering conference and symposium on the foundations of software engineering, pp. 152–162, 2018

    2018

  27. [36]

    Static inference meets deep learning: a hybrid type inference approach for python,

    Y . Peng, C. Gao, Z. Li, B. Gao, D. Lo, Q. Zhang, and M. Lyu, “Static inference meets deep learning: a hybrid type inference approach for python,” inProceedings of the 44th International Conference on Software Engineering, pp. 2019–2030, 2022. 11

    2019

  28. [37]

    Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation,

    Y . Wang, W. Wang, S. Joty, and S. C. Hoi, “Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation,”arXiv preprint arXiv:2109.00859, 2021

    2021 arXiv

  29. [38]

    On the naturalness of software,

    P. T. Devanbu, “On the naturalness of software,”2012 34th International Conference on Software Engineering (ICSE), pp. 837–847, 2012

    2012

  30. [39]

    Code completion with statistical language models,

    V . Raychev, M. T. Vechev, and E. Yahav, “Code completion with statistical language models,”Proceedings of the 35th ACM SIGPLAN Conference on Programming Language Design and Implementation, 2014

    2014

  31. [40]

    Pythia: Ai- assisted code completion system,

    A. Svyatkovskiy, Y . Zhao, S. Fu, and N. Sundaresan, “Pythia: Ai- assisted code completion system,” inProceedings of the 25th ACM SIGKDD international conference on knowledge discovery & data mining, pp. 2727–2735, 2019

    2019

  32. [41]

    Oreo: Detection of clones in the twilight zone,

    V . Saini, F. Farmahinifarahani, Y . Lu, P. Baldi, and C. V . Lopes, “Oreo: Detection of clones in the twilight zone,” inProceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, pp. 354...

    2018

  33. [42]

    Learning graph-based code representations for source-level functional similarity detection,

    J. Liu, J. Zeng, X. Wang, and Z. Liang, “Learning graph-based code representations for source-level functional similarity detection,” in2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE), pp. 345–357, IEEE, 2023

    2023

  34. [43]

    Sequencer: Sequence-to-sequence learning for end- to-end program repair,

    Z. Chen, S. Kommrusch, M. Tufano, L.-N. Pouchet, D. Poshyvanyk, and M. Monperrus, “Sequencer: Sequence-to-sequence learning for end- to-end program repair,”IEEE Transactions on Software Engineering, vol. 47, no. 9, pp. 1943–1959, 2019

    1943

  35. [44]

    Applying codebert for automated pro- gram repair of java simple bugs,

    E. Mashhadi and H. Hemmati, “Applying codebert for automated pro- gram repair of java simple bugs,” in2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR), pp. 505–509, IEEE, 2021

    2021

  36. [45]

    Hoppity: Learning graph transformations to detect and fix bugs in programs,

    E. Dinella, H. Dai, Z. Li, M. Naik, L. Song, and K. Wang, “Hoppity: Learning graph transformations to detect and fix bugs in programs,” in International Conference on Learning Representations (ICLR), 2020

    2020

  37. [46]

    Programl: Graph-based deep learning for program optimization and analysis,

    C. Cummins, Z. V . Fisches, T. Ben-Nun, T. Hoefler, and H. Leather, “Programl: Graph-based deep learning for program optimization and analysis,” 2020

    2020

  38. [47]

    Ffl: Fine-grained fault localization for student programs via syntactic and semantic reasoning,

    T.-D. Nguyen, T. Le-Cong, D.-M. Luong, V .-H. Duong, X.-B. D. Le, D. Lo, and Q.-T. Huynh, “Ffl: Fine-grained fault localization for student programs via syntactic and semantic reasoning,” in2022 IEEE Interna- tional Conference on Software Maintenance and Evolution (ICSME), pp....

    2022

  39. [48]

    Boosting coverage-based fault localization via graph-based representation learning,

    Y . Lou, Q. Zhu, J. Dong, X. Li, Z. Sun, D. Hao, L. Zhang, and L. Zhang, “Boosting coverage-based fault localization via graph-based representation learning,” inProceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundatio...

    2021

  40. [49]

    Language mod- els are few-shot learners,

    T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell,et al., “Language mod- els are few-shot learners,”Advances in neural information processing systems, vol. 33, pp. 1877–1901, 2020

    1901

  41. [50]

    A neural model for gener- ating natural language summaries of program subroutines,

    A. LeClair, S. Jiang, and C. McMillan, “A neural model for gener- ating natural language summaries of program subroutines,” in2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE), pp. 795–806, IEEE, 2019

    2019

  42. [51]

    Vulcurator: a vulnerability-fixing commit detector,

    T. G. Nguyen, T. Le-Cong, H. J. Kang, X.-B. D. Le, and D. Lo, “Vulcurator: a vulnerability-fixing commit detector,” inProceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, pp. 1726–1730, 2022

    2022

  43. [52]

    Codebert: A pre-trained model for programming and natural languages,

    Z. Feng, D. Guo, D. Tang, N. Duan, X. Feng, M. Gong, L. Shou, B. Qin, T. Liu, D. Jiang,et al., “Codebert: A pre-trained model for programming and natural languages,”arXiv preprint arXiv:2002.08155, 2020

    2002 arXiv

  44. [53]

    Scelmo: Source code embeddings from language models,

    R.-M. Karampatsis and C. Sutton, “Scelmo: Source code embeddings from language models,”arXiv preprint arXiv:2004.13214, 2020

    2004 arXiv

  45. [54]

    Graphcodebert: Pre- training code representations with data flow,

    D. Guo, S. Ren, S. Lu, Z. Feng, D. Tang, S. Liu, L. Zhou, N. Duan, A. Svyatkovskiy, S. Fu, M. Tufano, S. K. Deng, C. Clement, D. Drain, N. Sundaresan, J. Yin, D. Jiang, and M. Zhou, “Graphcodebert: Pre- training code representations with data flow,” 2021

    2021

  46. [55]

    code2seq: Generating sequences from structured representations of code,

    U. Alon, S. Brody, O. Levy, and E. Yahav, “code2seq: Generating sequences from structured representations of code,”arXiv preprint arXiv:1808.01400, 2018

    2018 arXiv

  47. [56]

    Structured neural summarization,

    P. Fernandes, M. Allamanis, and M. Brockschmidt, “Structured neural summarization,”arXiv preprint arXiv:1811.01824, 2018

    2018 arXiv

  48. [57]

    Gen- erative code modeling with graphs,

    M. Brockschmidt, M. Allamanis, A. L. Gaunt, and O. Polozov, “Gen- erative code modeling with graphs,”arXiv preprint arXiv:1805.08490, 2018

    2018 arXiv

  49. [58]

    Learning to represent edits,

    P. Yin, G. Neubig, M. Allamanis, M. Brockschmidt, and A. L. Gaunt, “Learning to represent edits,”arXiv preprint arXiv:1810.13337, 2018. 12

    2018 arXiv

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.