Added support for atomic vectors #1245
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Slartibartfass2
force-pushed
the
1142-add-support-for-atomic-vectors-field-sensitive-pointer-analysis
branch
3 times, most recently
from
e0f55e2 to
199b3f0
Compare
Slartibartfass2
force-pushed
the
1142-add-support-for-atomic-vectors-field-sensitive-pointer-analysis
branch
3 times, most recently
from
bbe8c41 to
b4f8b0a
Compare
Slartibartfass2
force-pushed
the
1142-add-support-for-atomic-vectors-field-sensitive-pointer-analysis
branch
2 times, most recently
from
8e7099c to
92932de
Compare
2 tasks
Slartibartfass2
force-pushed
the
1142-add-support-for-atomic-vectors-field-sensitive-pointer-analysis
branch
from
7701ce9 to
6fc92b6
Compare
Slartibartfass2
force-pushed
the
1142-add-support-for-atomic-vectors-field-sensitive-pointer-analysis
branch
from
a1f9d36 to
e18c129
Compare
This reduces the indentation of the whole pointer analysis block and the argument filtering before can be excluded too.
While lexemes are great to destinguish indices from named arguments in lists, for vectors we need to also store the index. Furthermore, this is important for index based access on lists or vectors. Index information for named arguments will be added separately.
These will be required later for the index based access on lists.
For an expression `c(1, 2, c(3, 4))` the nested vector would be flattened so that it equals `c(1, 2, 3, 4)`. For this to work, we need to fetch the indices for the nested vector and add them to the existing indices. In a case where there are values after a nested index we need to rewrite the indices so that they are in correct order. E.g. for `c(1, c(2, 3), 4)` the argument with value '4' has initially the index 3, after it has been flattened, it has to be 4. This is done by merging both lists with new indices similar to the merging part of MergeSort.
With this test suite we can test whether the indices of a vector are defined correctly. Previously we only could check this by accessing the indices and testing the reads edges. This eliminates this step and lets us test this unit separately.
Previously only numbers were recognized as values for a vector definition.
Now we can use the same method for the index based access, which works in the same way.
- removed 'dataflow' prefix, because the tests are in the `test/functionality/dataflow` directory, which makes the prefix obsolete - added the type of access to the test files: list-access -> list-name-based-access to differentiate other types of access
On the way down, we don't have all information e.g. about nested containers, which makes it inevitable to resolve them on the way up. Previously, for a vector definition nested containers were handled on the way up, while primitves were handled on the way down. This lead to a rather complex merging logic. Handling now everything on the way up let's us iterate the arguments once and define the indices for the container at the same time. While adding the resolving of unnamed list arguments, I changed this too for list definitions.
These functions are now used for all container logic.
This enabled the pointer analysis for assignments like the following: ```r a <- c(1, 2) a[[1]] <- 3 a[2] <- 4 ``` This does not include access with a variable or a range or anything that accessed more than one index.
This way, we can test the same behavior for vectors and lists (with named and unnamed arguments).
This enables it e.g. to query the second access operation in the same line, which was previously only possible using the line:column format.
This enables passing the indices of one container to another. Example: ```r a <- c(1, 2) b <- a # indices [1, 2] are passed to b print(b) # definition of a is also in slice ```
Now all edge types can be created using queries.
This way, we can extend the test suite and test more scenarios in less code/time.
Slartibartfass2
force-pushed
the
1142-add-support-for-atomic-vectors-field-sensitive-pointer-analysis
branch
from
fef4e56 to
938b340
Compare
2 tasks
EagleoutIce
deleted the
1142-add-support-for-atomic-vectors-field-sensitive-pointer-analysis
branch
|
This pull request is included in v2.2.12 (see Release v2.2.12 (Vector Support, Improved Graphic Support, Eval of Strings)). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #1142
Closes #1144
What changed:
c(1, 2, 3, 4)[[1]]and[1]container1 <- container2(indices are copied)a1f9d365)assertContainerIndicesDefinitionassertion function