gh-126835: Move constant unaryop & binop folding to CFG

[WolframAlph]

• Issue: Move const folding to the peephole optimizer #126835

This PR migrates:

1. Unary ops optimizations from AST to CFG.
2. All binary ops optimizations from AST to CFG except for string formatting. FTR: Move const folding to the peephole optimizer #126835 (comment)

cc @Eclips4@tomasr8

[tomasr8]

Do we also want to check for invalid expressions like duplicate mapping keys? For example:

matchx:
case {0j: y, 0j: z} ...

[WolframAlph]

They won't trigger error here, this is only ast parsing phase. Error is emitted in codegen.

[tomasr8]

yeah but it's not tested anywhere currently and since we're changing the logic around match, it feels safer to make sure we don't change something accidentally. Though I don't insist on adding it in this PR, it's more of a general comment

[WolframAlph]

We should test that, but I am not sure if in this PR as it only touches AST related logic.

[iritkatriel]

You can add tests covering various aspects of the feature you're touching.

[WolframAlph]

@iritkatriel CI reports unused functions, but we need them in assertions. So either mark them as used or convert them to macros I guess?

[iritkatriel]

@iritkatriel CI reports unused functions, but we need them in assertions. So either mark them as used or convert them to macros I guess?

Put them under #ifndef NDEBUG.

[WolframAlph]

I've addressed review & simplifed match pattern folding. One question remaining whether we should add tests with hand crafted ast with invalid expressions in match statement case.

[iritkatriel]

Looks good!

[iritkatriel]

This is looking good. I made some final minor comments.

Are you still planning to add tests for invalid hand-crafted ASTs?

[WolframAlph]

Done. Honestly I don't think we need them. We already test folding in match cases quite extensively, and current folding is the same as previous, just for limited expressions. We could add them for completeness, but probably in another PR as this one is getting quite big. But if you think we need them, I could add to this.

[iritkatriel]

Sure.

[iritkatriel]

It would be good to add smoke tests to make sure we don't crash on invalid ast input. Can be in another pr.

[WolframAlph]

Thanks @iritkatriel for guidance & patience.

[iritkatriel]

!buildbot refleak

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @iritkatriel for commit cafbc61 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F129550%2Fmerge

The command will test the builders whose names match following regular expression: refleak

The builders matched are:

• aarch64 RHEL8 Refleaks PR
• s390x RHEL8 Refleaks PR
• AMD64 RHEL8 Refleaks PR
• AMD64 FreeBSD Refleaks PR
• PPC64LE Fedora Stable Refleaks PR
• PPC64LE CentOS9 Refleaks PR
• AMD64 CentOS9 NoGIL Refleaks PR
• AMD64 Fedora Stable Refleaks PR
• AMD64 Fedora Rawhide NoGIL refleaks PR
• aarch64 Fedora Stable Refleaks PR
• PPC64LE Fedora Rawhide Refleaks PR
• AMD64 CentOS9 Refleaks PR
• PPC64LE RHEL8 Refleaks PR
• s390x RHEL9 Refleaks PR
• ARM64 MacOS M1 Refleaks NoGIL PR
• AMD64 Windows11 Refleaks PR
• PPC64LE Fedora Rawhide NoGIL refleaks PR
• AMD64 Fedora Rawhide Refleaks PR
• aarch64 Fedora Rawhide Refleaks PR
• aarch64 CentOS9 Refleaks PR
• aarch64 Fedora Rawhide NoGIL refleaks PR