Conversation
|
With this patch we are down to 31 failed tests. It'd be great to merge the 3.14 into the CI as a separate PR so we can see the results here. |
15r10nk
force-pushed
the
3.14
branch
3 times, most recently
from
cc340e5 to
71e11cf
Compare
|
I'd be nice to move this forward. Python 3.14 is beta 3 now so no breaking changes are expected anymore. |
15r10nk
force-pushed
the
3.14
branch
2 times, most recently
from
e1a9923 to
2b43bfa
Compare
|
@frenzymadness, thank you for reminding me. I fixed some issues (mostly part of the verification and not in the algo). I also found a cpython issue python/cpython#135700 and hope that it can be fixed because it hard to work around it in executing. |
|
Python 3.14.0 release candidate 2 was released yesterday. The final release will be on 7 October. |
15r10nk
force-pushed
the
3.14
branch
2 times, most recently
from
18b953f to
90b6317
Compare
|
hi @alexmojaki, This one is almost ready. The open problem with 3.9 is caused by one new small sample which are part of this pr. This problem can be fixed with #95. Can we merge it before this one? |
|
@alexmojaki I think you can review this. |
executing/_position_node_finder.py
Outdated
| # https://github.com/python/cpython/issues/135700 | ||
| raise KnownIssue("synthetic opcodes in annotations are just bound to the first node") | ||
|
|
||
| if self.frame.f_code.co_name=="__annotate__" and instruction.opname=="STORE_SUBSCR": |
There was a problem hiding this comment.
does this mean executing won't work inside a function called __annotate__?
There was a problem hiding this comment.
You are right, this is what it currently does. What it should do is handle some instructions in annotations, and only those. Will fix it.
There was a problem hiding this comment.
I think it is not possible to make this more precise.
This is one example which fails when I remove this code:
[0]
unique_name_0: 0
unique_name_1: 0 The problem here is that the unique_name_0: 0 creates a STORE_SUBSCR in the middle of the annotate bytecode.
50 1:0 1:3 STORE_SUBSCR() VerifierFailure: ast.List is not created
from STORE_SUBSCR
And this bytecode is mapped to [0] which is completely unrelated to the annotation (it happens to be the first statement in the file).
It is general possible to map instructions in annotations to ast-nodes, but the problem is that the synthetic generated instructions are mapped to an unrelated ast-node (the first in the file). This issue describes the problem.
I have currently no better idea to work around this problem.
There was a problem hiding this comment.
I think I have found a way.
There was a problem hiding this comment.
so is it ready for re-review?
alexmojaki
left a comment
alexmojaki
left a comment
There was a problem hiding this comment.
Thanks! It all looks a bit crazy but oh well, doesn't seem to hurt the common use cases.
|
Yes, it is a bit crazy how these annotations are implemented. This causes several exceptions for our current tests. I hope I can simplify it in the future. |
|
Merge if you're happy |
3 participants
No description provided.