Add 3.12 typing features to the compiler

[dchiquito]

This is the first step towards implementing 3.12 compliant typing(#5252 ) . It's taken me a long time to get this far so I wanted to check in before spending more time building on this foundation.

Changes made:

• Add the builtin _typing stdlib module. This will eventually replace the fundamental typing primitives that are currently implemented in typing.py. This is still very much a work in progress, but it works well enough to exercise the new compiler features.
• Compile and evaluate function generics (def foo[X](x: X): ...)
• Compile and evaluate class generics (class C[X]: def __init__(x: X): ...)
• Compile type alias statements (type X = list[int])

Some questions:

• The push_symbol_table and pop_symbol_table are my attempt to simulate the behavior of the new Annotation Scopes. I'm not sure if I got this 100% right.
• At some point, CPython introduced the compiler-level concept of intrinsics. There are a handful of instructions like CALL_INTRINSIC_1 and CALL_INTRINSIC_2 that do weird fundamental python things like printing, importing, or defining types. It seems to me that this is mostly a way of organizing the code than a fundamental design requirement, so I ignored this and added the intrinsics I needed as instructions. Perhaps this is not correct?
• I made a small change to how the bookkeeping is done for unmarshalling bytecode. Adding a new instruction caused me some very odd intermittent errors that took me a while to debug, so my hope is to prevent headaches in the future.

[youknowone]

Awesome! I like the changes.

The push_symbol_table and pop_symbol_table are my attempt to simulate the behavior of the new Annotation Scopes. I'm not sure if I got this 100% right.

To be honest, I don't know well about either Annotation Scopes or our symbol table. If you are not sure about the design, leaving a comment with your concern will be fine.
@coolreader18 Do you have any advice?

At some point, CPython introduced the compiler-level concept of intrinsics. There are a handful of instructions like CALL_INTRINSIC_1 and CALL_INTRINSIC_2 that do weird fundamental python things like printing, importing, or defining types. It seems to me that this is mostly a way of organizing the code than a fundamental design requirement, so I ignored this and added the intrinsics I needed as instructions. Perhaps this is not correct?

Yes, CPython is recently very quickly changing its instruction design. Our instructions design is staying around 3.6~3.8. Your approach seems correct and fits in traditional Python instruction design well. We will be able to introduce those new concepts later. Don't worry!

I made a small change to how the bookkeeping is done for unmarshalling bytecode. Adding a new instruction caused me some very odd intermittent errors that took me a while to debug, so my hope is to prevent headaches in the future.

I am sorry to make you to be confused. How about placing a comment to the last instruction like "Please add instruction in the middle of the enum; otherwise LAST_INSTRUCTION need to be updated"

[dchiquito]

Thanks for the feedback! Would you prefer keeping this branch separate until typing is finished or merging it now?

[youknowone]

I prefer to merge small patches, frequently. I will review this patch soon, thank you so much!

[youknowone]

Awesome, finally we have _typing!

I also tried #4946 on it. _typing look like almost close to working.

Thank you for making a big progress 😄