Basic USVM TS type system with type coercion #215
Conversation
…rgeyl/ts_typecoercion
# Conflicts: # usvm-core/src/main/kotlin/org/usvm/StateForker.kt # usvm-ts/src/main/kotlin/org/usvm/TSInterpreter.kt
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
detekt found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.
|
This PR indirectly introduces a bug |
|
|
||
| class TSTestResolver { | ||
| class TSTestResolver( | ||
| private val state: TSState |
There was a problem hiding this comment.
Why? Resolver should be able to resolve many states independently
There was a problem hiding this comment.
TSTestResolver was instantiated for each returned state, and I needed access to state.typeStorage.
So I decided to add state as private constructor param.
| private fun approximateParam(expr: UConcreteHeapRef, idx: Int, model: UModelBase<EtsType>): TSObject = | ||
| with(expr.ctx as TSContext) { | ||
| val suggestedType = state.getSuggestedType(idx) | ||
| return suggestedType?.let { newType -> |
There was a problem hiding this comment.
Something odd is happening here. You can always access all required information using symbolic values and symbolic values only, otherwise you will encounter path divergence. This map cannot be built from concrete values to type info, only from symbolic ones
There was a problem hiding this comment.
I believe different types of ref entities (reg readings, etc.) have unique ways to generate a key. For example, reg readings can use its' idx field as a key, and this key leads to correct list of types from any model.
| @@ -1,15 +1,18 @@ | |||
| package org.usvm.util | |||
|
|
|||
| import java.nio.file.Paths | |||
Check warning
Code scanning / detekt
Detects imports in non default order Warning test
No description provided.