@eagleoutice/flowr 2.1.8 → 2.1.10

package/dataflow/internal/process/functions/call/common.js

@@ -35,7 +35,7 @@ function forceVertexArgumentValueReferences(rootId, value, graph, env) {
     // try to resolve them against the current environment
     for (const ref of [...value.in, ...containedSubflowIn.flatMap(n => n.subflow.in)]) {
         if (ref.name) {
-            const resolved = (0, resolve_by_name_1.resolveByName)(ref.name, env, ref.type) ?? [];
+            const resolved = ref.name ? (0, resolve_by_name_1.resolveByName)(ref.name, env, ref.type) ?? [] : [];
             for (const resolve of resolved) {
                 graph.addEdge(ref.nodeId, resolve.nodeId, edge_1.EdgeType.Reads);
             }
@@ -77,7 +77,12 @@ function processAllArguments({ functionName, args, data, finalGraph, functionRoo
                     if ((0, info_1.happensInEveryBranch)(resolved.controlDependencies)) {
                         assumeItMayHaveAHigherTarget = false;
                     }
-                    finalGraph.addEdge(ingoing.nodeId, resolved.nodeId, edge_1.EdgeType.Reads);
+                    // When only a single index is referenced, we don't need to reference the whole object
+                    const resolvedInGraphDef = resolved;
+                    const isContainer = checkForContainer(resolvedInGraphDef?.indicesCollection);
+                    if (isContainer || isContainer === undefined) {
+                        finalGraph.addEdge(ingoing.nodeId, resolved.nodeId, edge_1.EdgeType.Reads);
+                    }
                 }
                 if (assumeItMayHaveAHigherTarget) {
                     remainingReadInArgs.push(ingoing);
@@ -113,4 +118,13 @@ function patchFunctionCall({ nextGraph, rootId, name, data, argumentProcessResul
         }
     }
 }
+/**
+ * Check whether passed {@link indices} are containers or whether their sub-indices are containers.
+ */
+function checkForContainer(indices) {
+    return indices?.every((indices) => {
+        const areSubIndicesContainers = indices.indices.every(index => 'subIndices' in index && checkForContainer(index.subIndices));
+        return indices.isContainer || areSubIndicesContainers;
+    });
+}
 //# sourceMappingURL=common.js.map

package/dataflow/internal/process/functions/call/known-call-handling.d.ts

@@ -8,6 +8,7 @@ import type { NodeId } from '../../../../../r-bridge/lang-4.x/ast/model/processi
 import type { RNode } from '../../../../../r-bridge/lang-4.x/ast/model/model';
 import type { IdentifierReference } from '../../../../environments/identifier';
 import { DataflowGraph } from '../../../../graph/graph';
+import type { ContainerIndicesCollection } from '../../../../graph/vertex';
 export interface ProcessKnownFunctionCallInput<OtherInfo> extends ForceArguments {
     readonly name: RSymbol<OtherInfo & ParentInformation>;
     readonly args: readonly (RNode<OtherInfo & ParentInformation> | RFunctionArgument<OtherInfo & ParentInformation>)[];
@@ -28,4 +29,4 @@ export interface ProcessKnownFunctionCallResult {
     readonly fnRef: IdentifierReference;
 }
 export declare function markNonStandardEvaluationEdges(markAsNSE: readonly number[], callArgs: readonly (DataflowInformation | undefined)[], finalGraph: DataflowGraph, rootId: NodeId): void;
-export declare function processKnownFunctionCall<OtherInfo>({ name, args, rootId, data, reverseOrder, markAsNSE, forceArgs, patchData, hasUnknownSideEffect }: ProcessKnownFunctionCallInput<OtherInfo>): ProcessKnownFunctionCallResult;
+export declare function processKnownFunctionCall<OtherInfo>({ name, args, rootId, data, reverseOrder, markAsNSE, forceArgs, patchData, hasUnknownSideEffect }: ProcessKnownFunctionCallInput<OtherInfo>, indicesCollection?: ContainerIndicesCollection): ProcessKnownFunctionCallResult;

package/dataflow/internal/process/functions/call/known-call-handling.js

@@ -23,7 +23,7 @@ function markNonStandardEvaluationEdges(markAsNSE, callArgs, finalGraph, rootId)
         }
     }
 }
-function processKnownFunctionCall({ name, args, rootId, data, reverseOrder = false, markAsNSE = undefined, forceArgs, patchData = d => d, hasUnknownSideEffect }) {
+function processKnownFunctionCall({ name, args, rootId, data, reverseOrder = false, markAsNSE = undefined, forceArgs, patchData = d => d, hasUnknownSideEffect }, indicesCollection = undefined) {
     const functionName = (0, processor_1.processDataflowFor)(name, data);
     const finalGraph = new graph_1.DataflowGraph(data.completeAst.idMap);
     const functionCallName = name.content;
@@ -41,7 +41,8 @@ function processKnownFunctionCall({ name, args, rootId, data, reverseOrder = fal
         /* will be overwritten accordingly */
         onlyBuiltin: false,
         controlDependencies: data.controlDependencies,
-        args: reverseOrder ? [...callArgs].reverse() : callArgs
+        args: reverseOrder ? [...callArgs].reverse() : callArgs,
+        indicesCollection: indicesCollection,
     });
     if (hasUnknownSideEffect) {
         finalGraph.markIdForUnknownSideEffects(rootId);

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

@@ -10,7 +10,6 @@ export interface PrintDataflowGraphOptions {
     readonly codeOpen?: boolean;
     readonly exposeResult?: boolean;
     readonly switchCodeAndGraph?: boolean;
-    readonly hideEnvInMermaid?: boolean;
 }
 export declare function formatSideEffect(ef: UnknownSidEffect): string;
 export declare function printDfGraphForCode(shell: RShell, code: string, options: PrintDataflowGraphOptions & {

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

@@ -32,7 +32,7 @@ function formatSideEffect(ef) {
         return `${ef}`;
     }
 }
-async function printDfGraphForCode(shell, code, { mark, showCode = true, codeOpen = false, exposeResult, switchCodeAndGraph = false, hideEnvInMermaid = false } = {}) {
+async function printDfGraphForCode(shell, code, { mark, showCode = true, codeOpen = false, exposeResult, switchCodeAndGraph = false } = {}) {
     const now = performance.now();
     const result = await new pipeline_executor_1.PipelineExecutor(default_pipelines_1.DEFAULT_DATAFLOW_PIPELINE, {
         shell,
@@ -60,19 +60,6 @@ We encountered ${result.dataflow.graph.unknownSideEffects.size > 0 ? 'unknown si
 
 ${switchCodeAndGraph ? dfGraph : codeText}
 
-<details>
-
-<summary style="color:gray">Mermaid Code ${(mark?.size ?? 0) > 0 ? '(without markings)' : ''}</summary>
-
-\`\`\`
-${(0, dfg_1.graphToMermaid)({
-            graph: result.dataflow.graph,
-            prefix: 'flowchart LR',
-            includeEnvironments: !hideEnvInMermaid
-        }).string}
-\`\`\`
-
-</details>
 
 </details>
 

package/documentation/print-capabilities-markdown.js

@@ -39,7 +39,7 @@ function printAsMarkdown(capabilities, depth = 0, lines = []) {
 function getPreamble() {
     const currentDateAndTime = new Date().toISOString().replace('T', ', ').replace(/\.\d+Z$/, ' UTC');
     const shortenFilename = module.filename.replace(/^.*src\//, 'src/');
-    return `_This document was generated from '${shortenFilename}' on ${currentDateAndTime} summarizig flowR's current capabilities (v${(0, version_1.flowrVersion)().format()})._
+    return `_This document was generated from '${shortenFilename}' on ${currentDateAndTime} summarizing flowR's current capabilities (v${(0, version_1.flowrVersion)().format()})._
 
 The code-font behind each capability name is a link to the capability's id. This id can be used to reference the capability in a labeled test within flowR.
 Besides, we use colored bullets like this:

package/documentation/print-dataflow-graph-wiki.js

@@ -561,26 +561,45 @@ However, nested definitions can carry it (in the nested case, \`x\` is defined b
             code: 'foo <- function() x\nfoo()',
             expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().returns('2@foo', '1@x')
         }, []]);
+    const lateBindingExample = `
+f <- function() x
+x <- 3
+f()
+	`.trim();
+    const dfInfo = await (0, doc_dfg_1.printDfGraphForCode)(shell, lateBindingExample, { switchCodeAndGraph: true, codeOpen: true, mark: new Set([1, '1->5', '9->5']) });
     edgeExplanations.set(edge_1.EdgeType.DefinesOnCall, [{
             shell: shell,
             name: 'DefinesOnCall Edge',
             type: edge_1.EdgeType.DefinesOnCall,
-            description: `**This edge is automatically joined with ${linkEdgeName(edge_1.EdgeType.DefinedByOnCall)}!**
+            description: `*This edge is usually joined with ${linkEdgeName(edge_1.EdgeType.DefinedByOnCall)}!*
 
- Link an Argument to whichever parameter they cause to be defined if the related function call is invoked.`,
+ Links an Argument to whichever parameter they cause to be defined if the related function call is invoked.
+ 
+ In the context of functions which access their closure environment these edges play another tricky role as there are many cases 
+ made more difficult by R's way of allowing closure environments to later receive variables.
+ Consider the following scenario in which we first define a function which returns the value of a variable named \`x\` and then define \`x\`
+ only after we defined the function:
+   
+${dfInfo}
+
+ The final call evaluates to \`3\` (similar to if we would have defined \`x\` before the function definition).
+ Within a dataflow graph you can see this with two edges. The \`x\` within the function body will have a ${linkEdgeName(edge_1.EdgeType.DefinedByOnCall)} 
+ to every definition it _may_ refer to. In turn, each call vertex calling the function which encloses the use of \`x\` will have a
+ ${linkEdgeName(edge_1.EdgeType.DefinesOnCall)} edge to the definition(s) it causes to be active within the function body. 
+ `,
             code: 'f <- function(x) {}\nf(x=1)',
             // here we use the ids as the argument wrappers are not easily selected with slicing criteria
-            expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().definesOnCall('$11', '$1')
+            expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().definesOnCall('$11', '$1').definedByOnCall('$1', '$11')
         }, []]);
     edgeExplanations.set(edge_1.EdgeType.DefinedByOnCall, [{
             shell: shell,
             name: 'DefinedByOnCall Edge',
             type: edge_1.EdgeType.DefinedByOnCall,
-            description: `**This edge is automatically joined with ${linkEdgeName(edge_1.EdgeType.DefinesOnCall)}!**
+            description: `*This edge is usually joined with ${linkEdgeName(edge_1.EdgeType.DefinesOnCall)}!*
 
- This represents the other direction of ${linkEdgeName(edge_1.EdgeType.DefinesOnCall)} (i.e., links the parameter to the argument). This is just for completeness.`,
+ This represents the other part of the ${linkEdgeName(edge_1.EdgeType.DefinesOnCall)} edge (e.g., links the parameter to the argument). Please look there for further documentation.`,
             code: 'f <- function(x) {}\nf(x=1)',
-            expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().definesOnCall('$11', '$1')
+            expectedSubgraph: (0, dataflowgraph_builder_1.emptyGraph)().definesOnCall('$11', '$1').definedByOnCall('$1', '$11')
         }, []]);
     edgeExplanations.set(edge_1.EdgeType.Argument, [{
             shell: shell,
@@ -611,7 +630,7 @@ Marks cases in which R's non-standard evaluation mechanisms cause the default se
 ${(0, doc_structure_1.block)({
                 type: 'NOTE',
                 content: `
-What to do if you encounter this vertex? 
+What to do if you encounter a vertex marked with this edge? 
 
 This depends on your analysis. To handle many real-world sources correctly you are probably fine with just ignoring it.
 Yet, you may choose to follow these references for other queries. For now, _flowR's_ support for non-standard evaluation is limited.

package/documentation/print-interface-wiki.js

@@ -171,6 +171,7 @@ The following summarizes the configuration options:
 - \`semantics\`: allows to configure the way _flowR_ handles R, although we currently only support \`semantics/environment/overwriteBuiltIns\`. 
   You may use this to overwrite _flowR_'s handling of built-in function and even completely clear the preset definitions shipped with flowR. 
   See [Configure BuiltIn Semantics](#configure-builtin-semantics) for more information.
+- \`solver\`: allows to configure how _flowR_ resolves variables and their values (currently we support: ${Object.values(config_1.VariableResolve).map(v => `\`${v}\``).join(', ')}), as well as if pointer analysis should be active.
 
 So you can configure _flowR_ by adding a file like the following:
 
@@ -189,6 +190,10 @@ ${(0, doc_code_1.codeBlock)('json', JSON.stringify({
                     ]
                 }
             }
+        },
+        solver: {
+            variables: config_1.VariableResolve.Alias,
+            pointerTracking: true
         }
     }, null, 2))}
 
@@ -233,7 +238,7 @@ _flowR_ can be used as a [module](${doc_files_1.FlowrNpmRef}) and offers several
 ### Using the \`${shell_1.RShell.name}\` to Interact with R
 
 The \`${shell_1.RShell.name}\` class allows to interface with the \`R\` ecosystem installed on the host system.
-For now there are no (real) alternatives, although we plan on providing more flexible drop-in replacements.
+For now, there are no (real) alternatives, although we plan on providing more flexible drop-in replacements.
 
 > [!IMPORTANT]
 > Each \`${shell_1.RShell.name}\` controls a new instance of the R interpreter, make sure to call \`${shell_1.RShell.name}::${shell.close.name}()\` when you’re done.

package/documentation/print-linting-and-testing-wiki.js

@@ -3,9 +3,10 @@ Object.defineProperty(exports, "__esModule", { value: true });
 const log_1 = require("../../test/functionality/_helper/log");
 const doc_code_1 = require("./doc-util/doc-code");
 const doc_files_1 = require("./doc-util/doc-files");
+const doc_structure_1 = require("./doc-util/doc-structure");
 function getText() {
     return `
-For the latest code-coverage information, see [codecov.io](${doc_files_1.FlowrCodecovRef}), 
+For the latest code coverage information, see [codecov.io](${doc_files_1.FlowrCodecovRef}), 
 for the latest benchmark results, see the [benchmark results](${doc_files_1.FlowrSiteBaseRef}/wiki/stats/benchmark) wiki page.
 
 - [Testing Suites](#testing-suites)
@@ -13,32 +14,37 @@ for the latest benchmark results, see the [benchmark results](${doc_files_1.Flow
     - [Test Structure](#test-structure)
     - [Writing a Test](#writing-a-test)
     - [Running Only Some Tests](#running-only-some-tests)
+  - [System Tests](#system-tests)
   - [Performance Tests](#performance-tests)
   - [Oh no, the tests are slow](#oh-no-the-tests-are-slow)
   - [Testing Within Your IDE](#testing-within-your-ide)
-    - [Using Visual Studio Code](#vs-code)
-    - [Using WebStorm](#webstorm)
+    - [VS Code](#vs-code)
+    - [Webstorm](#webstorm)
 - [CI Pipeline](#ci-pipeline)
 - [Linting](#linting)
   - [Oh no, the linter fails](#oh-no-the-linter-fails)
   - [License Checker](#license-checker)
+- [Debugging](#debugging)
+  - [VS Code](#vs-code-1)
 
 ## Testing Suites
 
-Currently, flowR contains two testing suites: one for [functionality](#functionality-tests) and one for [performance](#performance-tests). We explain each of them in the following.
-In addition to running those tests, you can use the more generalized \`npm run checkup\`. This will include the construction of the docker image, the generation of the wiki pages, and the linter.
+Currently, flowR contains three testing suites: one for [functionality](#functionality-tests), 
+one for [system tests](#system-tests), and one for [performance](#performance-tests). We explain each of them in the following.
+In addition to running those tests, you can use the more generalized \`npm run checkup\`. 
+This command includes the construction of the docker image, the generation of the wiki pages, and the linter.
 
 ### Functionality Tests
 
 The functionality tests represent conventional unit (and depending on your terminology component/api) tests.
 We use [vitest](https://vitest.dev/) as our testing framework.
-You can run the tests by issuing:
+You can run the tests by issuing (some quick benchmarks may be available with \`vitest bench\`):
 
 ${(0, doc_code_1.codeBlock)('shell', 'npm run test')}
 
 Within the commandline,
-this should automatically drop you into a watch mode which will automatically re-run the tests if you change the code.
-If, at any time there are too many errors, you can use \`--bail=<value>\` to stop the tests after a certain number of errors.
+this should automatically drop you into a watch mode which will automatically re-run (potentially) affected tests if you change the code.
+If, at any time there are too many errors for you to comprehend, you can use \`--bail=<value>\` to stop the tests after a certain number of errors.
 For example:
 
 ${(0, doc_code_1.codeBlock)('shell', 'npm run test -- --bail=1')}
@@ -51,10 +57,10 @@ To run all tests, including a coverage report and label summary, run:
 
 ${(0, doc_code_1.codeBlock)('shell', 'npm run test-full')}
 
-However, depending on your local R version, your network connection and potentially other factors, some tests may be skipped automatically as they don't apply to your current system setup 
-(or can't be tested with the current prerequisites). 
+However, depending on your local version of&nbsp;R, your network connection, and other factors (each test may have a set of criteria), 
+some tests may be skipped automatically as they do not apply to your current system setup (or cannot be tested with the current prerequisites). 
 Each test can specify such requirements as part of the \`TestConfiguration\`, which is then used in the \`test.skipIf\` function of _vitest_.
-It is up to the [ci](#ci-pipeline) to run the tests on different systems to ensure that those tests are ensured to run.
+It is up to the [ci](#ci-pipeline) to run the tests on different systems to ensure that those tests run.
 
 #### Test Structure
 
@@ -62,12 +68,18 @@ All functionality tests are to be located under [test/functionality](${doc_files
 
 This folder contains three special and important elements:
 
-- \`test-setup\` which is the entry point if *all* tests are run. It should automatically disable logging statements and configure global variables (e.g., if installation tests should run).
-- \`_helper\` which contains helper functions to be used by other tests.
-- \`test-summary\` which may produce a summary of the covered capabilities.
+- \`test-setup.ts\` which is the entry point if *all* tests are run. It should automatically disable logging statements and configure global variables (e.g., if installation tests should run).
+- \`_helper/\` folder which contains helper functions to be used by other tests.
+- \`test-summary.ts\` which may produce a summary of the covered capabilities.
 
-We name all tests using the \`.test.ts\` suffix and try to run them in parallel. 
-Whenever this is not possible (e.g., when using \`withShell\`), please use \`describe.sequential\` to disable parallel execution for the respective test.
+${(0, doc_structure_1.block)({
+        type: 'WARNING',
+        content: `
+We name all test files using the \`.test.ts\` suffix and try to run them in parallel.
+Whenever this is not possible (e.g., when using \`withShell\`), please use \`describe.sequential\`
+to disable parallel execution for the respective test (otherwise, such tests are flaky).
+`
+    })}
 
 #### Writing a Test
 
@@ -86,10 +98,11 @@ assertDataflow(label('simple variable', ['name-normal']), shell,
 `)}
 
 When writing dataflow tests, additional settings can be used to reduce the amount of graph data that needs to be pre-written. Notably:
+
 - \`expectIsSubgraph\` indicates that the expected graph is a subgraph, rather than the full graph that the test should generate. The test will then only check if the supplied graph is contained in the result graph, rather than an exact match.
 - \`resolveIdsAsCriterion\` indicates that the ids given in the expected (sub)graph should be resolved as [slicing criteria](${doc_files_1.FlowrWikiBaseRef}/Terminology#slicing-criterion) rather than actual ids. For example, passing \`12@a\` as an id in the expected (sub)graph will cause it to be resolved as the corresponding id.
 
-The following example shows both in use.
+The following example shows both in use:
 ${(0, doc_code_1.codeBlock)('typescript', `
 assertDataflow(label('without distractors', [...OperatorDatabase['<-'].capabilities, 'numbers', 'name-normal', 'newlines', 'name-escaped']),
 	shell, '\`a\` <- 2\\na',
@@ -108,10 +121,25 @@ assertDataflow(label('without distractors', [...OperatorDatabase['<-'].capabilit
 To run only some tests, vitest allows you to [filter](https://vitest.dev/guide/filtering.html) tests. 
 Besides, you can use the watch mode (with \`npm run test\`) to only run tests that are affected by your changes.
 
+### System Tests
+
+In contrast to the [functionality tests](#functionality-tests), the system tests use runners like the \`npm\` scripts
+to test the behavior of the whole system, for example, by running the CLI or the server.
+They are slower and hence not part of \`npm run test\` but can be run using:
+${(0, doc_code_1.codeBlock)('shell', 'npm run test:system')}
+To work, they require you to set up your system correctly (e.g., have \`npm\` available on your path).
+The CI environment will make sure of that. At the moment, these tests are not labeled and only intended
+to check basic availability of *flowR*'s core features (as we test the functionality of these features dedicately 
+with the [functionality tests](#functionality-tests)).
+
+Have a look at the [test/system-tests](${doc_files_1.RemoteFlowrFilePathBaseRef}test/system-tests) folder for more information.
+ 
+
+
 ### Performance Tests
 
 The performance test suite of *flowR* uses several suites to check for variations in the required times for certain steps.
-Although we measure wall time in the CI (which is subject to rather large variations), it should give a rough idea of the performance of *flowR*.
+Although we measure wall time in the CI (which is subject to rather large variations), it should give a rough idea *flowR*'s performance.
 Furthermore, the respective scripts can be used locally as well.
 To run them, issue:
 
@@ -143,18 +171,18 @@ Please follow the official guide [here](https://www.jetbrains.com/help/webstorm/
 
 ## CI Pipeline
 
-We have several workflows defined in [.github/workflows](../.github/workflows/).
+We have several workflows defined in [.github/workflows](${doc_files_1.RemoteFlowrFilePathBaseRef}/.github/workflows/).
 We explain the most important workflows in the following:
 
-- [qa.yaml](../.github/workflows/qa.yaml) is the main workflow that will run different steps depending on several factors. It is responsible for:
+- [qa.yaml](${doc_files_1.RemoteFlowrFilePathBaseRef}/.github/workflows/qa.yaml) is the main workflow that will run different steps depending on several factors. It is responsible for:
   - running the [functionality](#functionality-tests) and [performance tests](#performance-tests)
     - uploading the results to the [benchmark page](${doc_files_1.FlowrSiteBaseRef}/wiki/stats/benchmark) for releases
     - running the [functionality tests](#functionality-tests) on different operating systems (Windows, macOS, Linux) and with different versions of R
     - reporting code coverage
   - running the [linter](#linting) and reporting its results
   - deploying the documentation to [GitHub Pages](${doc_files_1.FlowrSiteBaseRef}/doc/)
-- [release.yaml](../.github/workflows/release.yaml) is responsible for creating a new release, only to be run by repository owners. Furthermore, it adds the new docker image to [docker hub](${doc_files_1.FlowrDockerRef}).
-- [broken-links-and-wiki.yaml](../.github/workflows/broken-links-and-wiki.yaml) repeatedly tests that all links are not dead!
+- [release.yaml](${doc_files_1.RemoteFlowrFilePathBaseRef}/.github/workflows/release.yaml) is responsible for creating a new release, only to be run by repository owners. Furthermore, it adds the new docker image to [docker hub](${doc_files_1.FlowrDockerRef}).
+- [broken-links-and-wiki.yaml](${doc_files_1.RemoteFlowrFilePathBaseRef}/.github/workflows/broken-links-and-wiki.yaml) repeatedly tests that all links are not dead!
 
 ## Linting
 
@@ -163,11 +191,11 @@ The main one:
 
 ${(0, doc_code_1.codeBlock)('shell', 'npm run lint')}
 
-And a weaker version of the first (allowing for *todo* comments) which is run automatically in the [pre-push githook](../.githooks/pre-push) as explained in the [CONTRIBUTING.md](../.github/CONTRIBUTING.md):
+And a weaker version of the first (allowing for *todo* comments) which is run automatically in the [pre-push githook](${doc_files_1.RemoteFlowrFilePathBaseRef}/.githooks/pre-push) as explained in the [CONTRIBUTING.md](${doc_files_1.RemoteFlowrFilePathBaseRef}/.github/CONTRIBUTING.md):
 
 ${(0, doc_code_1.codeBlock)('shell', 'npm run lint-local')}
 
-Besides checking coding style (as defined in the [package.json](../package.json)), the *full* linter runs the [license checker](#license-checker).
+Besides checking coding style (as defined in the [package.json](${doc_files_1.RemoteFlowrFilePathBaseRef}/package.json)), the *full* linter runs the [license checker](#license-checker).
 
 In case you are unaware,
 eslint can automatically fix several linting problems[](https://eslint.org/docs/latest/use/command-line-interface#fix-problems).
@@ -178,14 +206,20 @@ ${(0, doc_code_1.codeBlock)('shell', 'npm run lint-local -- --fix')}
 ### Oh no, the linter fails
 
 By now, the rules should be rather stable and so, if the linter fails,
-it is usually best if you (if necessary) read the respective description and fix the respective problem.
+it is usually best if you (when necessary) read the respective description and fix the respective problem.
 Rules in this project cover general JavaScript issues [using regular ESLint](https://eslint.org/docs/latest/rules), TypeScript-specific issues [using typescript-eslint](https://typescript-eslint.io/rules/), and code formatting [with ESLint Stylistic](https://eslint.style/packages/default#rules).
 
 However, in case you think that the linter is wrong, please do not hesitate to open a [new issue](${doc_files_1.FlowrGithubBaseRef}/flowr/issues/new/choose).
 
 ### License Checker
 
-*flowR* is licensed under the [GPLv3 License](${doc_files_1.FlowrGithubBaseRef}/flowr/blob/main/LICENSE) requiring us to only rely on [compatible licenses](https://www.gnu.org/licenses/license-list.en.html). For now, this list is hardcoded as part of the npm [\`license-compat\`](../package.json) script so it can very well be that a new dependency you add causes the checker to fail &mdash; *even though it is compatible*. In that case, please either open a [new issue](${doc_files_1.FlowrGithubBaseRef}/flowr/issues/new/choose) or directly add the license to the list (including a reference to why it is compatible).
+*flowR* is licensed under the [GPLv3 License](${doc_files_1.FlowrGithubBaseRef}/flowr/blob/main/LICENSE) requiring us to only rely on [compatible licenses](https://www.gnu.org/licenses/license-list.en.html). For now, this list is hardcoded as part of the npm [\`license-compat\`](${doc_files_1.RemoteFlowrFilePathBaseRef}/package.json) script so it can very well be that a new dependency you add causes the checker to fail &mdash; *even though it is compatible*. In that case, please either open a [new issue](${doc_files_1.FlowrGithubBaseRef}/flowr/issues/new/choose) or directly add the license to the list (including a reference to why it is compatible).
+
+
+## Debugging
+### VS Code
+When working with VS Code, you can attach a debugger to the REPL. This works automatically by running the \`Start Debugging\` command (\`F5\` by default).
+You can also set the \`Auto Attach Filter\` setting to automatically attach the debugger, when running \`npm run flowr\`.
 `;
 }
 if (require.main === module) {

package/documentation/print-query-wiki.js

@@ -418,7 +418,7 @@ ${(0, doc_query_1.tocForQueryType)('virtual')}
 
 Although it is probably better to consult the detailed explanations below, if you want to have a look at the scehma, here is its description:
 
-${(0, schema_1.describeSchema)(query_1.QueriesSchema, ansi_1.markdownFormatter)}
+${(0, schema_1.describeSchema)((0, query_1.QueriesSchema)(), ansi_1.markdownFormatter)}
 
 </details>
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@eagleoutice/flowr",
-  "version": "2.1.8",
+  "version": "2.1.10",
   "description": "Static Dataflow Analyzer and Program Slicer for the R Programming Language",
   "types": "dist/src/index.d.ts",
   "repository": {
@@ -36,12 +36,13 @@
     "lint": "npm run license-compat -- --summary && npx eslint --version && npx eslint src/ test/",
     "license-compat": "license-checker --onlyAllow 'MIT;MIT OR X11;GPLv2;LGPL;GNUGPL;ISC;Apache-2.0;FreeBSD;BSD-2-Clause;clearbsd;ModifiedBSD;BSD-3-Clause;Python-2.0;Unlicense;WTFPL;BlueOak-1.0.0;CC-BY-4.0;CC-BY-3.0;CC0-1.0;0BSD'",
     "doc": "typedoc",
-    "test": "vitest --config test/vitest.config.mts",
+    "test": "vitest --exclude \"test/system-tests/**\" --config test/vitest.config.mts",
+    "test:system": "vitest --dir test/system-tests --config test/system-tests/vitest.config.mts",
     "test:coverage": "npm run test -- --coverage",
     "performance-test": "func() { cd test/performance/ && bash run-all-suites.sh $1 $2 $3; cd ../../; }; func",
     "test-full": "npm run test:coverage -- --no-watch -- --make-summary --test-installation",
     "detect-circular-deps": "npx madge  --extensions ts,tsx --circular src/",
-    "checkup": "npm run flowr -- --execute \":version\" && npm run lint && npm run test-full -- --allowOnly=false && docker build -t test-flowr -f scripts/Dockerfile . && npm run doc && npm-run-all wiki:*"
+    "checkup": "npm run flowr -- --execute \":version\" && npm run lint && npm run test-full -- --allowOnly=false && npm run test:system -- --no-watch && docker build -t test-flowr -f scripts/Dockerfile . && npm run doc && npm-run-all wiki:*"
   },
   "keywords": [
     "static code analysis",
@@ -84,6 +85,19 @@
       "**/node_modules/**/*",
       "**/index.ts"
     ],
+    "highlightLanguages": [
+      "bash",
+      "console",
+      "css",
+      "html",
+      "javascript",
+      "json",
+      "jsonc",
+      "json5",
+      "tsx",
+      "typescript",
+      "r"
+    ],
     "theme": "hierarchy",
     "out": "doc",
     "readme": "README.md",

package/queries/catalog/call-context-query/call-context-query-executor.js

@@ -209,7 +209,7 @@ function executeCallContextQueries({ graph, ast }, queries) {
             let linkedIds = undefined;
             if (cfg && isSubCallQuery(query)) {
                 /* if we have a linkTo query, we have to find the last call */
-                const lastCall = (0, identify_link_to_last_call_relation_1.identifyLinkToLastCallRelation)(nodeId, cfg.graph, graph, query.linkTo.callName);
+                const lastCall = (0, identify_link_to_last_call_relation_1.identifyLinkToLastCallRelation)(nodeId, cfg.graph, graph, query.linkTo);
                 if (lastCall) {
                     linkedIds = lastCall;
                 }

package/queries/catalog/call-context-query/call-context-query-format.d.ts

@@ -6,6 +6,9 @@ import Joi from 'joi';
 import type { PipelineOutput } from '../../../core/steps/pipeline/pipeline';
 import type { DEFAULT_DATAFLOW_PIPELINE } from '../../../core/steps/pipeline/default-pipelines';
 import { CallTargets } from './identify-link-to-last-call-relation';
+import type { DataflowGraph } from '../../../dataflow/graph/graph';
+import type { DataflowGraphVertexInfo } from '../../../dataflow/graph/vertex';
+import type { CascadeAction } from './cascade-action';
 export interface FileFilter<FilterType> {
     /**
      * Regex that a node's file attribute must match to be considered
@@ -52,6 +55,16 @@ interface LinkToLastCall<CallName extends RegExp | string = RegExp | string> ext
     readonly type: 'link-to-last-call';
     /** Regex regarding the function name of the last call. Similar to {@link DefaultCallContextQueryFormat#callName}, strings are interpreted as a `RegExp`. */
     readonly callName: CallName;
+    /**
+     * Should we ignore this (source) call?
+     * Currently, there is no well working serialization for this.
+     */
+    readonly ignoreIf?: (id: NodeId, graph: DataflowGraph) => boolean;
+    /**
+     * Should we continue searching after the link was created?
+     * Currently, there is no well working serialization for this.
+     */
+    readonly cascadeIf?: (target: DataflowGraphVertexInfo, from: NodeId, graph: DataflowGraph) => CascadeAction;
 }
 export type LinkTo<CallName extends RegExp | string> = LinkToLastCall<CallName>;
 export interface SubCallContextQueryFormat<CallName extends RegExp | string = RegExp | string> extends DefaultCallContextQueryFormat<CallName> {

package/queries/catalog/call-context-query/call-context-query-format.js

@@ -32,7 +32,9 @@ exports.CallContextQueryDefinition = {
         }).optional().description('Filter that, when set, a node\'s file attribute must match to be considered'),
         linkTo: joi_1.default.object({
             type: joi_1.default.string().valid('link-to-last-call').required().description('The type of the linkTo sub-query.'),
-            callName: joi_1.default.string().required().description('Regex regarding the function name of the last call. Similar to `callName`, strings are interpreted as a regular expression.')
+            callName: joi_1.default.string().required().description('Regex regarding the function name of the last call. Similar to `callName`, strings are interpreted as a regular expression.'),
+            ignoreIf: joi_1.default.function().optional().description('Should we ignore this (source) call? Currently, there is no well working serialization for this.'),
+            cascadeIf: joi_1.default.function().optional().description('Should we continue searching after the link was created? Currently, there is no well working serialization for this.')
         }).optional().description('Links the current call to the last call of the given kind. This way, you can link a call like `points` to the latest graphics plot etc.')
     }).description('Call context query used to find calls in the dataflow graph')
 };

package/queries/catalog/call-context-query/cascade-action.d.ts

@@ -0,0 +1,8 @@
+export declare enum CascadeAction {
+    /** The action is to start the cascade */
+    Stop = "stop",
+    /** The action is to continue the cascade */
+    Continue = "continue",
+    /** The action is to skip the current node */
+    Skip = "skip"
+}

package/queries/catalog/call-context-query/cascade-action.js

@@ -0,0 +1,13 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.CascadeAction = void 0;
+var CascadeAction;
+(function (CascadeAction) {
+    /** The action is to start the cascade */
+    CascadeAction["Stop"] = "stop";
+    /** The action is to continue the cascade */
+    CascadeAction["Continue"] = "continue";
+    /** The action is to skip the current node */
+    CascadeAction["Skip"] = "skip";
+})(CascadeAction || (exports.CascadeAction = CascadeAction = {}));
+//# sourceMappingURL=cascade-action.js.map

package/queries/catalog/call-context-query/identify-link-to-last-call-relation.d.ts

@@ -1,6 +1,10 @@
 import type { NodeId } from '../../../r-bridge/lang-4.x/ast/model/processing/node-id';
 import type { ControlFlowGraph } from '../../../util/cfg/cfg';
 import type { DataflowGraph } from '../../../dataflow/graph/graph';
+import type { DataflowGraphVertexFunctionCall } from '../../../dataflow/graph/vertex';
+import { RType } from '../../../r-bridge/lang-4.x/ast/model/type';
+import type { RNodeWithParent } from '../../../r-bridge/lang-4.x/ast/model/processing/decorate';
+import type { LinkTo } from './call-context-query-format';
 export declare enum CallTargets {
     /** call targets a function that is not defined locally (e.g., the call targets a library function) */
     OnlyGlobal = "global",
@@ -14,4 +18,10 @@ export declare enum CallTargets {
     Any = "any"
 }
 export declare function satisfiesCallTargets(id: NodeId, graph: DataflowGraph, callTarget: CallTargets): NodeId[] | 'no';
-export declare function identifyLinkToLastCallRelation(from: NodeId, cfg: ControlFlowGraph, graph: DataflowGraph, linkTo: RegExp): NodeId[];
+export declare function getValueOfArgument<Types extends readonly RType[] = readonly RType[]>(graph: DataflowGraph, call: DataflowGraphVertexFunctionCall | undefined, argument: {
+    name?: string;
+    index: number;
+}, additionalAllowedTypes?: Types): (RNodeWithParent & {
+    type: Types[number];
+}) | undefined;
+export declare function identifyLinkToLastCallRelation(from: NodeId, cfg: ControlFlowGraph, graph: DataflowGraph, { callName, ignoreIf, cascadeIf }: LinkTo<RegExp>): NodeId[];