possible bug with viper code in class

[rkompass]

Thank you jimmo,

that was fast:-) After compiling it in I can confirm it works.
I had a look at Peters example code pieces again and tested and found: The (Damiens) workaround is still needed.
I repeat the code:

Code: Select all

def foo():
    x : int = 0
    @micropython.viper
    def inner() -> int:
        nonlocal x
        q : int = int(x)
        q += 1
        x = q << 1 | 1  # <- workaround!
        return int(x)
    return inner

bar = foo()
bar()  # 1
bar()  # 2

It seems like there has to be a test whether assignment to an integer object is happening and then automatically applying the " << 1 | 1 " correction should work, at least for not too large integers. The other way round there is no automatism, as the explicit int(x) is needed.
From this the question comes to my mind:
Shouldn't there be a way to save undistorted (viper / machine) integers through different calls of viper functions?
This was the original problem in https://github.com/micropython/micropython/issues/8086 I suppose.

[jimmo]

I had a look at Peters example code pieces again and tested and found: The (Damiens) workaround is still needed.

Yeah, that's what I said in the bug -- I only fixed this specific case with store_attr. Solving the non-local case is more complicated.

Shouldn't there be a way to save undistorted (viper / machine) integers through different calls of viper functions?

Yep, for sure. But there are lots of different sequences that need to handle this and each one is slightly different.

[TheSilverBullet]

Sent a PR to fix this: https://github.com/micropython/micropython/pull/8888

Unfortunately it turns out to be not quite the same as Peter's issue, but that's a little bit more difficult... this one was a good warm-up

jimmo, just wanted to let you know.
I incorporated your fix into the sourcecode here, compiled and tested it today.
It works well. Again, thanks a lot for your help.