Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Move TrieNode from kotlinx.collections #194

Merged
merged 27 commits into from
Sep 17, 2024
Merged

Move TrieNode from kotlinx.collections #194

merged 27 commits into from
Sep 17, 2024

Conversation

oveeernight
Copy link
Contributor

No description provided.

github-advanced-security[bot]
github-advanced-security bot found potential problems Jul 11, 2024
View reviewed changes
Copy link

@github-advanced-security github-advanced-security bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

detekt found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

@Saloed Saloed self-requested a review July 12, 2024 11:25
@oveeernight oveeernight force-pushed the usvm-persistent-map branch 3 times, most recently from 25d037a to 1b433cb Compare July 21, 2024 14:04
@oveeernight oveeernight force-pushed the usvm-persistent-map branch 3 times, most recently from 01d7488 to 4c8408e Compare July 24, 2024 20:15
@oveeernight oveeernight requested a review from Saloed July 24, 2024 20:47
@oveeernight oveeernight force-pushed the usvm-persistent-map branch 2 times, most recently from 05b5b85 to 476761b Compare July 24, 2024 23:04
@oveeernight oveeernight marked this pull request as draft July 25, 2024 14:22
@oveeernight oveeernight force-pushed the usvm-persistent-map branch 2 times, most recently from 2e639dc to 0209271 Compare July 25, 2024 16:08
@oveeernight oveeernight requested a review from Saloed July 25, 2024 16:21
@oveeernight oveeernight marked this pull request as ready for review July 25, 2024 16:21
Saloed
Saloed requested changes Jul 26, 2024
View reviewed changes
usvm-core/src/main/kotlin/org/usvm/collection/map/primitive/UMapRegion.kt Outdated Show resolved Hide resolved
usvm-core/src/main/kotlin/org/usvm/collection/map/primitive/UMapRegionApi.kt Show resolved Hide resolved
usvm-core/src/main/kotlin/org/usvm/Mocks.kt Show resolved Hide resolved
usvm-core/src/main/kotlin/org/usvm/memory/Memory.kt Outdated Show resolved Hide resolved
usvm-core/src/main/kotlin/org/usvm/solver/Solver.kt Outdated Show resolved Hide resolved
...util/src/main/kotlin/org/usvm/collections/immutable/implementations/immutableMap/TrieNode.kt Outdated Show resolved Hide resolved
usvm-util/src/main/kotlin/org/usvm/collections/immutable/adapters/ReadOnlyCollectionAdapters.kt Outdated Show resolved Hide resolved
usvm-util/src/main/kotlin/org/usvm/collections/immutable/extensions.kt Outdated Show resolved Hide resolved
usvm-util/src/main/kotlin/org/usvm/collections/immutable/extensions.kt Outdated Show resolved Hide resolved
usvm-util/src/main/kotlin/org/usvm/collections/immutable/internal/ListImplementation.kt Outdated Show resolved Hide resolved
@Saloed
Copy link
Collaborator

Saloed commented Jul 26, 2024

Also, it seems that we should use new (or provided from somewhere) ownership in the UComposer. Currently, we can overwrite memory with an ownership from the memory during the composition.

@oveeernight
Copy link
Contributor Author

oveeernight commented Jul 26, 2024 •
edited
Loading

Also, it seems that we should use new (or provided from somewhere) ownership in the UComposer. Currently, we can overwrite memory with an ownership from the memory during the composition.

Can you clarify this? As i can see, composer stores model as memory, models are mutually shared between states, and composer.transform can modify shared memory. What else transform with default ownership can spoil?

@oveeernight oveeernight marked this pull request as draft July 26, 2024 17:35
@Saloed
Copy link
Collaborator

Saloed commented Jul 26, 2024 •
edited
Loading

Also, it seems that we should use new (or provided from somewhere) ownership in the UComposer. Currently, we can overwrite memory with an ownership from the memory during the composition.

Can you clarify this? As i can see, composer stores model as memory, models are mutually shared between states, and composer.transform can modify shared memory. What else transform with default ownership can spoil?

Composer can use any memory, not only the model. So, any applyTo operation can corrupt the underlying memory

@oveeernight
Copy link
Contributor Author

oveeernight commented Jul 27, 2024 •
edited
Loading

For now we use ownership of memory inside of composer. It seems to be logical, isn't it? We use default ownership only in case of model. Or probably we should provide ownership of memory that we are applying and change the ownership inside composer memory?

@oveeernight oveeernight marked this pull request as ready for review July 29, 2024 16:16
@oveeernight oveeernight requested a review from Saloed July 29, 2024 16:17
Saloed
Saloed requested changes Aug 5, 2024
View reviewed changes
usvm-core/src/main/kotlin/org/usvm/Mocks.kt Outdated Show resolved Hide resolved
usvm-core/src/main/kotlin/org/usvm/StepScope.kt Outdated Show resolved Hide resolved
usvm-core/src/main/kotlin/org/usvm/model/Model.kt Outdated Show resolved Hide resolved
usvm-util/src/main/kotlin/org/usvm/collections/immutable/internal/EndOfChain.kt Outdated Show resolved Hide resolved
...usvm/collections/immutable/implementations/immutableSet/UPersistentHashSetMutableIterator.kt Outdated Show resolved Hide resolved
usvm-util/src/main/kotlin/org/usvm/collections/immutable/extensions.kt Outdated Show resolved Hide resolved
usvm-core/src/main/kotlin/org/usvm/constraints/PathConstraints.kt Outdated Show resolved Hide resolved
usvm-core/src/main/kotlin/org/usvm/constraints/PathConstraints.kt Outdated Show resolved Hide resolved
@oveeernight oveeernight marked this pull request as draft August 6, 2024 10:53
@oveeernight oveeernight requested a review from Saloed August 6, 2024 15:47
@oveeernight oveeernight marked this pull request as ready for review August 6, 2024 17:17
@oveeernight
use UPersistentHashMap; introduce ownership
3cfaaf7
@oveeernight
add ownership in memory
8e5435a
@oveeernight
numeric constraints: reorder remove and get
615f4f0
@oveeernight
linter warnings fixes
3b0f863
@oveeernight
fix ownership flow; add ownership in type constraints
20c3bdf
@oveeernight
use default ownership in composer memory
67d0c90
@oveeernight
use memory ownership in memcpy, union, merge
710daa0
@oveeernight
fix ownership inheritance
7373405
@oveeernight
various fixes
7eacc3b
@oveeernight
add ownership in composer
f7935bb
@oveeernight
fixes
72d9980
@oveeernight
change pc.ownership in clone
f244d7e
@oveeernight
remove scope.ownership
e5595f4
@oveeernight
fixes
b9808c8
@oveeernight
fix set iterator
3a2a421
@oveeernight
fix iterator
81dba08
@oveeernight
iterate sequence only once in JcStaticFieldsRegion
1252a45
@oveeernight
fix mutable iterators in NumericConstraints
4c56aa1
@oveeernight
add equals, hashCode, toString
f8178c0
@oveeernight
drop RegionTree
10e7b78
@oveeernight
fix hashCode, equals; fix union in map, set
7e96444
@oveeernight
move some logic in extensions
0a8a908
@oveeernight
toList in equalityConstrints
b7ceb0a
@oveeernight
fix compile err
a757b45
@oveeernight
add toList in some iterators
6677dbf
@oveeernight
style
b233828
@Saloed Saloed merged commit 0acf657 into UnitTestBot:main Sep 17, 2024
2 checks passed
@oveeernight oveeernight deleted the usvm-persistent-map branch September 17, 2024 13:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Saloed Saloed Saloed approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@oveeernight @Saloed