@eagleoutice/flowr 2.2.13 → 2.2.14

package/README.md

@@ -51,7 +51,7 @@ It offers a wide variety of features, for example:
     
     ```shell
     $ docker run -it --rm eagleoutice/flowr # or npm run flowr 
-    flowR repl using flowR v2.2.12, R v4.4.3 (r-shell engine)
+    flowR repl using flowR v2.2.13, R v4.4.3 (r-shell engine)
     R> :slicer test/testfiles/example.R --criterion "11@sum"
     ```
     
@@ -98,7 +98,7 @@ It offers a wide variety of features, for example:
         
 
 * 🚀 **fast data- and control-flow graphs**\
-  Within just <i><span title="This measurement is automatically fetched from the latest benchmark!">124.8 ms</span></i> (as of Mar 17, 2025), 
+  Within just <i><span title="This measurement is automatically fetched from the latest benchmark!">139.5 ms</span></i> (as of May 27, 2025), 
   _flowR_ can analyze the data- and control-flow of the average real-world R script. See the [benchmarks](https://flowr-analysis.github.io/flowr/wiki/stats/benchmark) for more information,
   and consult the [wiki pages](https://github.com/flowr-analysis/flowr/wiki/Dataflow-Graph) for more details on the dataflow graph.
 
@@ -134,7 +134,7 @@ It offers a wide variety of features, for example:
     
     ```shell
     $ docker run -it --rm eagleoutice/flowr # or npm run flowr 
-    flowR repl using flowR v2.2.12, R v4.4.3 (r-shell engine)
+    flowR repl using flowR v2.2.13, R v4.4.3 (r-shell engine)
     R> :dataflow* test/testfiles/example.R
     ```
     
@@ -435,7 +435,7 @@ It offers a wide variety of features, for example:
     ```
     
     	
-    (The analysis required _22.6 ms_ (including parse and normalize, using the [r-shell](https://github.com/flowr-analysis/flowr/wiki/Engines) engine) within the generation environment.)
+    (The analysis required _22.0 ms_ (including parse and normalize, using the [r-shell](https://github.com/flowr-analysis/flowr/wiki/Engines) engine) within the generation environment.)
     
     
     

package/cli/repl/commands/repl-cfg.d.ts

@@ -1,5 +1,5 @@
 import type { ReplCommand } from './repl-main';
 export declare const controlflowCommand: ReplCommand;
 export declare const controlflowStarCommand: ReplCommand;
-export declare const controlflowBBCommand: ReplCommand;
-export declare const controlflowBBStarCommand: ReplCommand;
+export declare const controlflowBbCommand: ReplCommand;
+export declare const controlflowBbStarCommand: ReplCommand;

package/cli/repl/commands/repl-cfg.js

@@ -33,7 +33,7 @@ var __importStar = (this && this.__importStar) || (function () {
     };
 })();
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.controlflowBBStarCommand = exports.controlflowBBCommand = exports.controlflowStarCommand = exports.controlflowCommand = void 0;
+exports.controlflowBbStarCommand = exports.controlflowBbCommand = exports.controlflowStarCommand = exports.controlflowCommand = void 0;
 const extract_cfg_1 = require("../../../control-flow/extract-cfg");
 const default_pipelines_1 = require("../../../core/steps/pipeline/default-pipelines");
 const retriever_1 = require("../../../r-bridge/retriever");
@@ -53,7 +53,7 @@ function formatInfo(out, type) {
 }
 async function produceAndPrintCfg(shell, remainingLine, output, simplifications, cfgConverter) {
     const result = await controlflow(shell, handleString(remainingLine));
-    const cfg = (0, extract_cfg_1.extractCFG)(result.normalize, result.dataflow.graph, [...cfg_simplification_1.DefaultCfgSimplificationOrder, ...simplifications]);
+    const cfg = (0, extract_cfg_1.extractCfg)(result.normalize, result.dataflow.graph, [...cfg_simplification_1.DefaultCfgSimplificationOrder, ...simplifications]);
     const mermaid = cfgConverter(cfg, result.normalize);
     output.stdout(mermaid);
     try {
@@ -82,7 +82,7 @@ exports.controlflowStarCommand = {
         await produceAndPrintCfg(shell, remainingLine, output, [], cfg_1.cfgToMermaidUrl);
     }
 };
-exports.controlflowBBCommand = {
+exports.controlflowBbCommand = {
     description: `Get mermaid code for the control-flow graph with basic blocks, start with '${retriever_1.fileProtocol}' to indicate a file`,
     usageExample: ':controlflowbb',
     aliases: ['cfgb', 'cfb'],
@@ -91,7 +91,7 @@ exports.controlflowBBCommand = {
         await produceAndPrintCfg(shell, remainingLine, output, ['to-basic-blocks'], cfg_1.cfgToMermaid);
     }
 };
-exports.controlflowBBStarCommand = {
+exports.controlflowBbStarCommand = {
     description: 'Returns the URL to mermaid.live',
     usageExample: ':controlflowbb*',
     aliases: ['cfgb*', 'cfb*'],

package/cli/repl/commands/repl-commands.js

@@ -85,8 +85,8 @@ const _commands = {
     'dataflowsimple*': repl_dataflow_1.dataflowSimpleStarCommand,
     'controlflow': repl_cfg_1.controlflowCommand,
     'controlflow*': repl_cfg_1.controlflowStarCommand,
-    'controlflowbb': repl_cfg_1.controlflowBBCommand,
-    'controlflowbb*': repl_cfg_1.controlflowBBStarCommand,
+    'controlflowbb': repl_cfg_1.controlflowBbCommand,
+    'controlflowbb*': repl_cfg_1.controlflowBbStarCommand,
     'lineage': repl_lineage_1.lineageCommand,
     'query': repl_query_1.queryCommand,
     'query*': repl_query_1.queryStarCommand

package/cli/repl/server/connection.js

@@ -160,7 +160,7 @@ class FlowRServerConnection {
     async sendFileAnalysisResponse(slicer, results, message) {
         let cfg = undefined;
         if (message.cfg) {
-            cfg = (0, extract_cfg_1.extractCFG)(results.normalize, results.dataflow?.graph);
+            cfg = (0, extract_cfg_1.extractCfg)(results.normalize, results.dataflow?.graph);
         }
         const config = () => ({ context: message.filename ?? 'unknown', getId: (0, quads_1.defaultQuadIdGenerator)() });
         const sanitizedResults = sanitizeAnalysisResults(results);

package/cli/script-core/statistics-helper-core.js

@@ -58,7 +58,7 @@ async function getStatsForSingleFile(options) {
     if (stats.outputs.size === 1) {
         if (options['dump-json']) {
             const [, output] = [...stats.outputs.entries()][0];
-            const cfg = (0, extract_cfg_1.extractCFG)(output.normalize, output.dataflow.graph);
+            const cfg = (0, extract_cfg_1.extractCfg)(output.normalize, output.dataflow.graph);
             statistics_file_1.statisticsFileProvider.append('output-json', 'parse', await (0, print_1.printStepResult)(_00_parse_1.PARSE_WITH_R_SHELL_STEP, output.parse, 2 /* StepOutputFormat.Json */));
             statistics_file_1.statisticsFileProvider.append('output-json', 'normalize', await (0, print_1.printStepResult)(_10_normalize_1.NORMALIZE, output.normalize, 2 /* StepOutputFormat.Json */));
             statistics_file_1.statisticsFileProvider.append('output-json', 'dataflow', await (0, print_1.printStepResult)(_20_dataflow_1.STATIC_DATAFLOW, output.dataflow, 2 /* StepOutputFormat.Json */));

package/control-flow/extract-cfg.d.ts

@@ -14,9 +14,9 @@ import type { CfgSimplificationPassName } from './cfg-simplification';
  *
  * @see {@link extractSimpleCfg} - for a simplified version of this function
  */
-export declare function extractCFG<Info = ParentInformation>(ast: NormalizedAst<Info>, graph?: DataflowGraph, simplifications?: readonly CfgSimplificationPassName[]): ControlFlowInformation;
+export declare function extractCfg<Info = ParentInformation>(ast: NormalizedAst<Info>, graph?: DataflowGraph, simplifications?: readonly CfgSimplificationPassName[]): ControlFlowInformation;
 /**
- * Simplified version of {@link extractCFG} that is much quicker, but much simpler!
+ * Simplified version of {@link extractCfg} that is much quicker, but much simpler!
  */
 export declare function extractSimpleCfg<Info = ParentInformation>(ast: NormalizedAst<Info>): ControlFlowInformation<import("./control-flow-graph").CfgSimpleVertex>;
 export declare const ResolvedCallSuffix = "-resolved-call-exit";

package/control-flow/extract-cfg.js

@@ -1,7 +1,7 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.ResolvedCallSuffix = void 0;
-exports.extractCFG = extractCFG;
+exports.extractCfg = extractCfg;
 exports.extractSimpleCfg = extractSimpleCfg;
 exports.cfg2quads = cfg2quads;
 const quads_1 = require("../util/quads");
@@ -62,11 +62,11 @@ function dataflowCfgFolds(dataflowGraph) {
  *
  * @see {@link extractSimpleCfg} - for a simplified version of this function
  */
-function extractCFG(ast, graph, simplifications) {
+function extractCfg(ast, graph, simplifications) {
     return (0, cfg_simplification_1.simplifyControlFlowInformation)((0, fold_1.foldAst)(ast.ast, graph ? dataflowCfgFolds(graph) : cfgFolds), simplifications);
 }
 /**
- * Simplified version of {@link extractCFG} that is much quicker, but much simpler!
+ * Simplified version of {@link extractCfg} that is much quicker, but much simpler!
  */
 function extractSimpleCfg(ast) {
     return (0, fold_1.foldAst)(ast.ast, cfgFolds);
@@ -272,11 +272,11 @@ function cfgFunctionCall(call, name, args, exit = 'exit') {
 exports.ResolvedCallSuffix = '-resolved-call-exit';
 function cfgFunctionCallWithDataflow(graph) {
     return (call, name, args) => {
-        const baseCFG = cfgFunctionCall(call, name, args);
+        const baseCfg = cfgFunctionCall(call, name, args);
         /* try to resolve the call and link the target definitions */
         const targets = (0, linker_1.getAllFunctionCallTargets)(call.info.id, graph);
         const exits = [];
-        const callVertex = baseCFG.graph.getVertex(call.info.id);
+        const callVertex = baseCfg.graph.getVertex(call.info.id);
         (0, assert_1.guard)(callVertex !== undefined, 'cfgFunctionCallWithDataflow: call vertex not found');
         for (const target of targets) {
             // we have to filter out non func-call targets as the call targets contains names and call ids
@@ -287,21 +287,21 @@ function cfgFunctionCallWithDataflow(graph) {
             }
         }
         if (exits.length > 0) {
-            baseCFG.graph.addVertex({
+            baseCfg.graph.addVertex({
                 id: call.info.id + exports.ResolvedCallSuffix,
                 type: control_flow_graph_1.CfgVertexType.EndMarker,
                 root: call.info.id
             });
-            for (const exit of [...baseCFG.exitPoints, ...exits]) {
-                baseCFG.graph.addEdge(call.info.id + exports.ResolvedCallSuffix, exit, { label: 0 /* CfgEdgeType.Fd */ });
+            for (const exit of [...baseCfg.exitPoints, ...exits]) {
+                baseCfg.graph.addEdge(call.info.id + exports.ResolvedCallSuffix, exit, { label: 0 /* CfgEdgeType.Fd */ });
             }
             return {
-                ...baseCFG,
+                ...baseCfg,
                 exitPoints: [call.info.id + exports.ResolvedCallSuffix]
             };
         }
         else {
-            return baseCFG;
+            return baseCfg;
         }
     };
 }

package/documentation/doc-util/doc-cfg.d.ts

@@ -19,5 +19,5 @@ export interface PrintCfgOptions {
     readonly simplify?: boolean;
     readonly useDfg?: boolean;
 }
-export declare function printCFGCode(parser: KnownParser, code: string, { showCode, openCode, prefix, simplifications, simplify, useDfg }?: PrintCfgOptions): Promise<string>;
+export declare function printCfgCode(parser: KnownParser, code: string, { showCode, openCode, prefix, simplifications, simplify, useDfg }?: PrintCfgOptions): Promise<string>;
 export {};

package/documentation/doc-util/doc-cfg.js

@@ -2,7 +2,7 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.getCfg = getCfg;
 exports.printCfg = printCfg;
-exports.printCFGCode = printCFGCode;
+exports.printCfgCode = printCfgCode;
 const extract_cfg_1 = require("../../control-flow/extract-cfg");
 const default_pipelines_1 = require("../../core/steps/pipeline/default-pipelines");
 const retriever_1 = require("../../r-bridge/retriever");
@@ -17,7 +17,7 @@ async function getCfg(parser, code, simplifications = [], useDfg = true) {
     }).allRemainingSteps() : await (0, default_pipelines_1.createNormalizePipeline)(parser, {
         request: (0, retriever_1.requestFromInput)(code)
     }).allRemainingSteps();
-    const cfg = (0, extract_cfg_1.extractCFG)(result.normalize, useDfg ? result.dataflow.graph : undefined, [...cfg_simplification_1.DefaultCfgSimplificationOrder, ...simplifications]);
+    const cfg = (0, extract_cfg_1.extractCfg)(result.normalize, useDfg ? result.dataflow.graph : undefined, [...cfg_simplification_1.DefaultCfgSimplificationOrder, ...simplifications]);
     return {
         info: cfg,
         ast: result.normalize,
@@ -29,7 +29,7 @@ function printCfg(cfg, ast, prefix = 'flowchart BT\n', simplify = false) {
 ${(0, doc_code_1.codeBlock)('mermaid', (0, cfg_1.cfgToMermaid)(cfg, ast, prefix, simplify))}
 	`;
 }
-async function printCFGCode(parser, code, { showCode = true, openCode = false, prefix = 'flowchart BT\n', simplifications = [], simplify = false, useDfg = true } = {}) {
+async function printCfgCode(parser, code, { showCode = true, openCode = false, prefix = 'flowchart BT\n', simplifications = [], simplify = false, useDfg = true } = {}) {
     const now = performance.now();
     const res = await getCfg(parser, code, simplifications, useDfg);
     const duration = performance.now() - now;

package/documentation/print-cfg-wiki.js

@@ -167,7 +167,7 @@ ${(0, doc_code_1.codeBlock)('r', 'x <- 2 * 3 + 1')}
 
 The corresponding CFG is a directed, labeled graph with two types of edges (control and flow dependencies).
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'x <- 2 * 3 + 1', { showCode: false, prefix: 'flowchart RL\n' })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'x <- 2 * 3 + 1', { showCode: false, prefix: 'flowchart RL\n' })}
 
 ${(0, doc_structure_1.block)({
         type: 'IMPORTANT',
@@ -180,30 +180,30 @@ Expressions, such as \`2 * 3\` get an additional node with an artificial id that
 
 To gain a better understanding, let's have a look at a simple program with a single branching structure:
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'if(u) 3 else 2', { showCode: true, openCode: false, prefix: 'flowchart RL\n' })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'if(u) 3 else 2', { showCode: true, openCode: false, prefix: 'flowchart RL\n' })}
 
 Here, you can see the \`if\` node followed by the condition (in this case merely \`u\`) that then splits into two branches for the two possible outcomes.
 The \`if\` structure is terminated by the corresponding \`-exit\` node (see the [structure](#cfg-structure) section for more details).
 
 For you to compare, the following shows the CFG of an \`if\` without an \`else\` branch:
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'if(u || v) 3', { showCode: true, openCode: false, prefix: 'flowchart RL\n' })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'if(u || v) 3', { showCode: true, openCode: false, prefix: 'flowchart RL\n' })}
 
 Activating the calculation of basic blocks produces the following:
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'if(u || v) 3', { showCode: true, openCode: false, prefix: 'flowchart RL\n', simplifications: ['to-basic-blocks'] })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'if(u || v) 3', { showCode: true, openCode: false, prefix: 'flowchart RL\n', simplifications: ['to-basic-blocks'] })}
 
 Which is probably much more readable if compacted (although the reconstucted code can sometimes be slightly mislieading as flowR tries its best to make it syntactically correct and hence add closing braces etc. which are technically not part of the respective block):
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'if(u || v) 3', { showCode: true, openCode: false, prefix: 'flowchart RL\n', simplifications: ['to-basic-blocks'], simplify: true })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'if(u || v) 3', { showCode: true, openCode: false, prefix: 'flowchart RL\n', simplifications: ['to-basic-blocks'], simplify: true })}
 
 The control flow graph also harmonizes with function definitions, and calls:
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'f <- function() { 3 }\nf()', { showCode: true, openCode: true, prefix: 'flowchart RL\n' })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'f <- function() { 3 }\nf()', { showCode: true, openCode: true, prefix: 'flowchart RL\n' })}
 
 ${(0, doc_structure_1.section)('Structure of the Control Flow Graph', 2, 'cfg-structure')}
 
-You can produce your very own control flow graph with ${(0, doc_types_1.shortLink)(extract_cfg_1.extractCFG.name, types.info)}.
+You can produce your very own control flow graph with ${(0, doc_types_1.shortLink)(extract_cfg_1.extractCfg.name, types.info)}.
 The ${(0, doc_types_1.shortLink)(control_flow_graph_1.ControlFlowGraph.name, types.info)} class describes everything required to model the control flow graph, with its edge types described by
  ${(0, doc_types_1.shortLink)('CfgEdge', types.info)} and its vertices by ${(0, doc_types_1.shortLink)('CfgSimpleVertex', types.info)}.
 However, you should be aware of the ${(0, doc_types_1.shortLink)('ControlFlowInformation', types.info)} interface which adds some additional information the the CFG
@@ -214,7 +214,7 @@ ${(0, doc_types_1.printHierarchy)({ info: types.info, root: 'ControlFlowInformat
 To check whether the CFG has the expected shape, you can use the test function ${(0, doc_types_1.shortLink)('assertCfg', testTypes.info)} which supports testing for
  sub-graphs as well (it provides diffing capabilities similar to ${(0, doc_types_1.shortLink)('assertDataflow', testTypes.info)}).
 As the CFG may become unhandy for larger programs, there are simplifications available with ${(0, doc_types_1.shortLink)(cfg_simplification_1.simplifyControlFlowInformation.name, types.info)}
-(these can be passed on to the ${(0, doc_types_1.shortLink)(extract_cfg_1.extractCFG.name, types.info)} function as well).
+(these can be passed on to the ${(0, doc_types_1.shortLink)(extract_cfg_1.extractCfg.name, types.info)} function as well).
 
 ${(0, doc_structure_1.section)('CFG Vertices', 3, 'cfg-structure-vertices')}
 
@@ -258,7 +258,7 @@ ${(0, doc_structure_1.section)('Flow Dependencies', 4, 'cfg-flow-dependency')}
 The most common edge is the flow dependency&nbsp;(FD) which simply signals that the source vertex happens _after_ the target vertex in the control flow.
 So \`x; y\` would produce a flow dependency from \`y\` to \`x\` (additionally to the program-enveloping root expression list):
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'x; y', { showCode: false, prefix: 'flowchart RL\n' })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'x; y', { showCode: false, prefix: 'flowchart RL\n' })}
 
 ${(0, doc_structure_1.section)('Control Dependencies', 4, 'cfg-control-dependency')}
 
@@ -271,12 +271,12 @@ The extra \`caused\` link signals the vertex that caused the control flow influe
 
 
 ${await (async () => {
-        const exa = await (0, doc_cfg_1.printCFGCode)(shell, 'if(u) 3 else 2', { showCode: true, prefix: 'flowchart RL\n' });
+        const exa = await (0, doc_cfg_1.printCfgCode)(shell, 'if(u) 3 else 2', { showCode: true, prefix: 'flowchart RL\n' });
         return (0, doc_structure_1.details)('Example: if-else', exa);
     })()}
 
 ${await (async () => {
-        const exa = await (0, doc_cfg_1.printCFGCode)(shell, 'while(u) b', { showCode: true, prefix: 'flowchart RL\n' });
+        const exa = await (0, doc_cfg_1.printCfgCode)(shell, 'while(u) b', { showCode: true, prefix: 'flowchart RL\n' });
         return (0, doc_structure_1.details)('Example: while-loop', exa);
     })()}
 <br/>
@@ -286,12 +286,12 @@ Additionally, the control flow graph does not have to be connected. If you use a
 the corresponding exit markers are not reachable from the entry:
 
 ${await (async () => {
-        const exa = await (0, doc_cfg_1.printCFGCode)(shell, 'repeat { b }; after', { showCode: true, prefix: 'flowchart RL\n' });
+        const exa = await (0, doc_cfg_1.printCfgCode)(shell, 'repeat { b }; after', { showCode: true, prefix: 'flowchart RL\n' });
         return (0, doc_structure_1.details)('Example: repeat-loop (infinite)', exa);
     })()}
 
 ${await (async () => {
-        const exa = await (0, doc_cfg_1.printCFGCode)(shell, 'repeat { b; if(u) break; }; after', { showCode: true, prefix: 'flowchart RL\n' });
+        const exa = await (0, doc_cfg_1.printCfgCode)(shell, 'repeat { b; if(u) break; }; after', { showCode: true, prefix: 'flowchart RL\n' });
         return (0, doc_structure_1.details)('Example: repeat-loop (with break)', exa);
     })()}
 <br/>
@@ -299,22 +299,22 @@ ${await (async () => {
 In the context of a for-loop, the control dependency refer to whether the respective vector still has values to iterate over.
 
 ${await (async () => {
-        const exa = await (0, doc_cfg_1.printCFGCode)(shell, 'for(i in 1:10) b', { showCode: true, prefix: 'flowchart RL\n' });
+        const exa = await (0, doc_cfg_1.printCfgCode)(shell, 'for(i in 1:10) b', { showCode: true, prefix: 'flowchart RL\n' });
         return (0, doc_structure_1.details)('Example: for-loop', exa);
     })()}
 
 ${(0, doc_structure_1.section)('Extra: Call Links', 4, 'cfg-call-links')}
 
-If you generate the CFG with the ${(0, doc_types_1.shortLink)(extract_cfg_1.extractCFG.name, types.info)} function you can (and, if you want to gain inter-procedural information, should)
+If you generate the CFG with the ${(0, doc_types_1.shortLink)(extract_cfg_1.extractCfg.name, types.info)} function you can (and, if you want to gain inter-procedural information, should)
 pass a matching [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow%20Graph) to it to incorporate the dataflow perspective into the CFG.
 
 The difference becomes obvious when we look at the code \`f <- function() b; f()\` first without the dataflow graph:
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'f <- function() b; f()', { showCode: true, prefix: 'flowchart RL\n', useDfg: false })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'f <- function() b; f()', { showCode: true, prefix: 'flowchart RL\n', useDfg: false })}
 
 And now, including dataflow information:
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'f <- function() b; f()', { showCode: true, prefix: 'flowchart RL\n', useDfg: true })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'f <- function() b; f()', { showCode: true, prefix: 'flowchart RL\n', useDfg: true })}
 
 There are two important additions:
 
@@ -325,7 +325,7 @@ There are two important additions:
 For built-in functions that are provided by flowR's built-in configuration (see the [interface wiki page](${doc_files_1.FlowrWikiBaseRef}/Interface)) the CFG does not contain
 the additional information directly:
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'print(3)', { showCode: true, prefix: 'flowchart RL\n' })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'print(3)', { showCode: true, prefix: 'flowchart RL\n' })}
 
 This is due to the fact that the [dataflow graph](${doc_files_1.FlowrWikiBaseRef}/Dataflow%20Graph) does contain the required call information (and there are no new control vertices to add as the built-in call has no target in the source code):
 
@@ -340,16 +340,16 @@ Yet, we can request basic blocks or transform an existing CFG into basic blocks
 
 Any program without any (un-)conditional jumps now contains a single basic block:
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'x <- 2 * 3 + 1', { showCode: true, openCode: true, prefix: 'flowchart RL\n', simplifications: ['to-basic-blocks'], simplify: true })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'x <- 2 * 3 + 1', { showCode: true, openCode: true, prefix: 'flowchart RL\n', simplifications: ['to-basic-blocks'], simplify: true })}
 
 While the CFG without basic blocks is much bigger:
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'x <- 2 * 3 + 1', { showCode: false, prefix: 'flowchart RL\n' })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'x <- 2 * 3 + 1', { showCode: false, prefix: 'flowchart RL\n' })}
 
 In a way, using the basic blocks perspective does not remove any of these vertices (we just usually visualize them compacted as their execution order should be "obvious").
 The vertices are still there, as elems of the ${(0, doc_types_1.shortLink)('CfgBasicBlockVertex', types.info)}:
 
-${await (0, doc_cfg_1.printCFGCode)(shell, 'x <- 2 * 3 + 1', { showCode: false, prefix: 'flowchart RL\n', simplifications: ['to-basic-blocks'], simplify: false })}
+${await (0, doc_cfg_1.printCfgCode)(shell, 'x <- 2 * 3 + 1', { showCode: false, prefix: 'flowchart RL\n', simplifications: ['to-basic-blocks'], simplify: false })}
 
 The benefit (for comprehensibility and algorithms) becomes more apparent when we look at a more complicated program:
 
@@ -357,12 +357,12 @@ ${(0, doc_code_1.codeBlock)('r', CfgLongExample)}
 
 With basic blocks, this code looks like this:
 
-${await (0, doc_cfg_1.printCFGCode)(shell, CfgLongExample, { showCode: false, prefix: 'flowchart RL\n', simplifications: ['to-basic-blocks'], simplify: true })}
+${await (0, doc_cfg_1.printCfgCode)(shell, CfgLongExample, { showCode: false, prefix: 'flowchart RL\n', simplifications: ['to-basic-blocks'], simplify: true })}
 
 Now, without basic blocks, this is a different story...
 
 ${await (async () => {
-        const exa = await (0, doc_cfg_1.printCFGCode)(shell, CfgLongExample, { showCode: false, prefix: 'flowchart RL\n' });
+        const exa = await (0, doc_cfg_1.printCfgCode)(shell, CfgLongExample, { showCode: false, prefix: 'flowchart RL\n' });
         return (0, doc_structure_1.details)('The full CFG', exa);
     })()}
 
@@ -529,7 +529,7 @@ ${await (async function () {
         (0, assert_1.guard)(plusVertex.type === control_flow_graph_1.CfgVertexType.Expression);
         const numOfExits = plusVertex.end?.length ?? 0;
         (0, assert_1.guard)(plusVertex.end && numOfExits === 1);
-        return `${await (0, doc_cfg_1.printCFGCode)(shell, 'x + 1', { showCode: true, prefix: 'flowchart RL\n' })}
+        return `${await (0, doc_cfg_1.printCfgCode)(shell, 'x + 1', { showCode: true, prefix: 'flowchart RL\n' })}
 	
 Looking at the binary operation vertex for \`+\` (with id \`${plusVertexId}\`) we see that it is linked to a single exit ("end marker") point: \`${plusVertex.end[0]}\`.
 Checking this vertex essentially reveals all exit points of the expression &dash; in this case, this simply refers to the operands of the addition.
@@ -544,7 +544,7 @@ ${(0, doc_structure_1.details)('Example: Exit Points for an if', await (async fu
         (0, assert_1.guard)(ifVertex.type === control_flow_graph_1.CfgVertexType.Statement);
         const numOfExits = ifVertex.end?.length ?? 0;
         (0, assert_1.guard)(ifVertex.end && numOfExits === 1);
-        return `${await (0, doc_cfg_1.printCFGCode)(shell, expr, { showCode: true, prefix: 'flowchart RL\n' })}
+        return `${await (0, doc_cfg_1.printCfgCode)(shell, expr, { showCode: true, prefix: 'flowchart RL\n' })}
 	
 Looking at the if vertex for (with id \`${ifVertexId}\`) we see that it is again linked to a single exit point: \`${ifVertex.end[0]}\`.
 Yet, now this exit vertex is linked to the two branches of the if statement (the \`then\` and \`else\` branch).

package/documentation/print-linter-wiki.d.ts

@@ -0,0 +1 @@
+export {};

package/documentation/print-linter-wiki.js

@@ -0,0 +1,76 @@
+"use strict";
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+const log_1 = require("../../test/functionality/_helper/log");
+const doc_auto_gen_1 = require("./doc-util/doc-auto-gen");
+const doc_files_1 = require("./doc-util/doc-files");
+const linter_rules_1 = require("../linter/linter-rules");
+const doc_code_1 = require("./doc-util/doc-code");
+const shell_1 = require("../r-bridge/shell");
+const doc_query_1 = require("./doc-util/doc-query");
+const doc_types_1 = require("./doc-util/doc-types");
+const path_1 = __importDefault(require("path"));
+async function getText(shell) {
+    const rVersion = (await shell.usedRVersion())?.format() ?? 'unknown';
+    return `${(0, doc_auto_gen_1.autoGenHeader)({ filename: module.filename, purpose: 'linter', rVersion })}
+
+This page describes the flowR linter, which is a tool that utilizes flowR's dataflow analysis to find common issues in R scripts. The linter can currently be used through the linter [query](${doc_files_1.FlowrWikiBaseRef}/Query%20API).
+
+## Linting Rules
+
+The following linting rules are available:
+
+${await rule(shell, 'deprecated-functions', 'DeprecatedFunctionsConfig', 'Deprecated Functions', 'This rule detects the usage of deprecated functions in code based on a predefined list of known deprecated functions.', `
+first <- data.frame(x = c(1, 2, 3), y = c(1, 2, 3))
+second <- data.frame(x = c(1, 3, 2), y = c(1, 3, 2))
+dplyr::all_equal(first, second)
+`)}
+
+${await rule(shell, 'file-path-validity', 'FilePathValidityConfig', 'File Path Validity', 'This rule finds places in the code where files are being read from. In such places, it checks whether the file path is valid and whether the file exists on disk.', `
+my_data <- read.csv("C:/Users/me/Documents/My R Scripts/Reproducible.csv")
+`)}
+
+    `.trim();
+}
+async function rule(shell, name, configType, friendlyName, description, example) {
+    const types = (0, doc_types_1.getTypesFromFolderAsMermaid)({
+        rootFolder: path_1.default.resolve('./src/linter/'),
+        typeName: configType,
+        inlineTypes: doc_types_1.mermaidHide
+    });
+    return `
+### ${friendlyName} (\`${name}\`)
+	
+${description}
+
+<details>
+
+#### Configuration
+
+Linting rules can be configured by passing a configuration object to the linter query as shown in the example below. The \`${name}\` rule accepts the following configuration options:
+
+${Object.getOwnPropertyNames(linter_rules_1.LintingRules[name].defaultConfig).sort().map(key => `- ${(0, doc_types_1.shortLink)(`${configType}:::${key}`, types.info)}\\\n${(0, doc_types_1.getDocumentationForType)(`${configType}::${key}`, types.info)}`).join('\n')}
+
+#### Example
+
+${(0, doc_code_1.codeBlock)('r', example)}
+
+The linting query can be used to run this rule on the above example:
+
+${await (0, doc_query_1.showQuery)(shell, example, [{ type: 'linter', rules: [{ name, config: {} }] }], { collapseQuery: true })}
+
+</details>
+	`.trim();
+}
+if (require.main === module) {
+    (0, log_1.setMinLevelOfAllLogs)(6 /* LogLevel.Fatal */);
+    const shell = new shell_1.RShell();
+    void getText(shell).then(str => {
+        console.log(str);
+    }).finally(() => {
+        shell.close();
+    });
+}
+//# sourceMappingURL=print-linter-wiki.js.map

package/linter/linter-executor.d.ts

@@ -0,0 +1,9 @@
+import type { LintingRuleConfig, LintingRuleNames } from './linter-rules';
+import type { NormalizedAst } from '../r-bridge/lang-4.x/ast/model/processing/decorate';
+import type { DataflowInformation } from '../dataflow/info';
+import type { LintingResults } from './linter-format';
+import type { DeepPartial } from 'ts-essentials';
+export declare function executeLintingRule<Name extends LintingRuleNames>(ruleName: Name, input: {
+    normalize: NormalizedAst;
+    dataflow: DataflowInformation;
+}, config?: DeepPartial<LintingRuleConfig<Name>>): LintingResults<Name>;

package/linter/linter-executor.js

@@ -0,0 +1,26 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.executeLintingRule = executeLintingRule;
+const linter_rules_1 = require("./linter-rules");
+const flowr_search_executor_1 = require("../search/flowr-search-executor");
+const flowr_search_1 = require("../search/flowr-search");
+function executeLintingRule(ruleName, input, config) {
+    const rule = linter_rules_1.LintingRules[ruleName];
+    const fullConfig = { ...rule.defaultConfig, ...config };
+    const ruleSearch = rule.createSearch(fullConfig, input);
+    const searchStart = Date.now();
+    const searchResult = (0, flowr_search_executor_1.runSearch)(ruleSearch, input);
+    const searchTime = Date.now() - searchStart;
+    const processStart = Date.now();
+    const result = rule.processSearchResult(new flowr_search_1.FlowrSearchElements(searchResult), fullConfig, input);
+    const processTime = Date.now() - processStart;
+    return {
+        ...result,
+        '.meta': {
+            ...result['.meta'],
+            searchTimeMs: searchTime,
+            processTimeMs: processTime
+        }
+    };
+}
+//# sourceMappingURL=linter-executor.js.map

package/linter/linter-format.d.ts

@@ -0,0 +1,65 @@
+import type { FlowrSearchLike } from '../search/flowr-search-builder';
+import type { FlowrSearchElement, FlowrSearchElements } from '../search/flowr-search';
+import type { MergeableRecord } from '../util/objects';
+import type { GeneratorNames } from '../search/search-executor/search-generators';
+import type { TransformerNames } from '../search/search-executor/search-transformer';
+import type { NormalizedAst, ParentInformation } from '../r-bridge/lang-4.x/ast/model/processing/decorate';
+import type { LintingRuleConfig, LintingRuleMetadata, LintingRuleNames, LintingRuleResult } from './linter-rules';
+import type { DataflowInformation } from '../dataflow/info';
+import type { DeepPartial } from 'ts-essentials';
+/**
+ * The base interface for a linting rule, which contains all of its relevant settings.
+ * The registry of valid linting rules is stored in {@link LintingRules}.
+ */
+export interface LintingRule<Result extends LintingResult, Metadata extends MergeableRecord, Config extends MergeableRecord = never, Info = ParentInformation, Elements extends FlowrSearchElement<Info>[] = FlowrSearchElement<Info>[]> {
+    /**
+     * Creates a flowR search that will then be executed and whose results will be passed to {@link processSearchResult}.
+     * In the future, additional optimizations and transformations may be applied to the search between this function and {@link processSearchResult}.
+     */
+    readonly createSearch: (config: Config, data: {
+        normalize: NormalizedAst;
+        dataflow: DataflowInformation;
+    }) => FlowrSearchLike<Info, GeneratorNames, TransformerNames[], FlowrSearchElements<Info, Elements>>;
+    /**
+     * Processes the search results of the search created through {@link createSearch}.
+     * This function is expected to return the linting results from this rule for the given search, ie usually the given script file.
+     */
+    readonly processSearchResult: (elements: FlowrSearchElements<Info, Elements>, config: Config, data: {
+        normalize: NormalizedAst;
+        dataflow: DataflowInformation;
+    }) => {
+        results: Result[];
+        '.meta': Metadata;
+    };
+    /**
+     * A function used to pretty-print the given linting result.
+     * By default, the {@link LintingResult#certainty} is automatically printed alongside this information.
+     */
+    readonly prettyPrint: (result: Result, metadata: Metadata) => string;
+    /**
+     * The default config for this linting rule.
+     * The default config is combined with the user config when executing the rule.
+     */
+    readonly defaultConfig: NoInfer<Config>;
+}
+/**
+ * A linting result for a single linting rule match.
+ */
+export interface LintingResult {
+    readonly certainty: LintingCertainty;
+}
+export interface ConfiguredLintingRule<Name extends LintingRuleNames = LintingRuleNames> {
+    readonly name: Name;
+    readonly config: DeepPartial<LintingRuleConfig<Name>>;
+}
+export interface LintingResults<Name extends LintingRuleNames> {
+    results: LintingRuleResult<Name>[];
+    '.meta': LintingRuleMetadata<Name> & {
+        readonly searchTimeMs: number;
+        readonly processTimeMs: number;
+    };
+}
+export declare enum LintingCertainty {
+    Maybe = "maybe",
+    Definitely = "definitely"
+}

package/linter/linter-format.js

@@ -0,0 +1,9 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.LintingCertainty = void 0;
+var LintingCertainty;
+(function (LintingCertainty) {
+    LintingCertainty["Maybe"] = "maybe";
+    LintingCertainty["Definitely"] = "definitely";
+})(LintingCertainty || (exports.LintingCertainty = LintingCertainty = {}));
+//# sourceMappingURL=linter-format.js.map