Code-Inspect / flowr

A program slicer and dataflow analyzer for the R programming language.
https://github.com/Code-Inspect/flowr/wiki
GNU General Public License v3.0
14 stars 2 forks source link

Reconstructing sourced files ignores sourcing #822

Open Ellpeck opened 1 month ago

Ellpeck commented 1 month ago

The following tests contain an expected reconstruction string that is not what we expect, given the reconstruction should include code from the sourced files too - either inline or by including the source line in the reconstruction. Nevertheless, these tests pass.

const sources = {
    simple:   'N <- 9',
    closure1: 'f <- function() { function() 3 }',
    closure2: 'f <- function() { x <<- 3 }'
}
setSourceProvider(requestProviderFromText(sources))

// these are incorrect - where is the content from the sourced file?
assertSliced(label('simple source', ['name-normal', ...OperatorDatabase['<-'].capabilities, 'numbers', 'unnamed-arguments', 'strings', 'sourcing-external-files','newlines']),
    shell, 'source("simple")\ncat(N)', ['2@N'], 'N')
assertSliced(label('sourcing a closure', ['name-normal', ...OperatorDatabase['<-'].capabilities, 'sourcing-external-files', 'newlines', 'normal-definition', 'implicit-return', 'closures', 'numbers']),
    shell, 'source("closure1")\ng <- f()\nprint(g())', ['3@g'], 'g <- f()\ng()')
assertSliced(label('sourcing a closure w/ side effects', ['name-normal', ...OperatorDatabase['<-'].capabilities, 'sourcing-external-files', 'newlines', 'normal-definition', 'implicit-return', 'closures', 'numbers', ...OperatorDatabase['<<-'].capabilities]),
    shell, 'x <- 2\nsource("closure2")\nf()\nprint(x)', ['4@x'], 'f()\nx')

As can be seen from this last test, the sourced content is taken into account for the slice, however, as the x <- 2 line is not part of the expected outpout since x is redefined in f.

EagleoutIce commented 1 month ago

Ok, so the dataflow graph is correct although we should add links to identify that all sourced nodes have a cd on the source call - can you make an issue for that @Ellpeck and get to it when you have the time?

Besides, actually updating the reconstruction to support this should be deferred to #484, allowing it to support the reconstruction of multiple files.