Open Sword-Smith opened 6 months ago
I am more than fine with removing type hints that destroy information. However, I don't understand the solution that seems to be suggested by the issue's title. What are “memory-stored values”? Perhaps that itself is not important and a re-phrasing will clarify things for me.
I am more than fine with removing type hints that destroy information. However, I don't understand the solution that seems to be suggested by the issue's title. What are “memory-stored values”? Perhaps that itself is not important and a re-phrasing will clarify things for me.
Sorry for being unclear. What I meant was that I think hints on values that are communicated to the caller can cause this problem.
If the type hints all had a number associated with them, the call graph depth where the type hint is defined, then whenever the call graph depth was decremented by one (on a return
or a recurse_or_return
), the type hints with a number higher than the VM's new call depth could be removed. I think that would fix all these problems.
If you manually add hints to a snippet A, these variable hints will carry over to snippet B that has A as a dependency. And in snippet B the variable name can be incorrect because the value is used in another context.
Example given below
The correct variable name here would have been
*scalars
or*challenges
, but since theDynMalloc
snippet contains the linehint free_page_address: Pointer = stack[0]
, this variable name is carried over through multiple calls.