Might be worth backporting this; it'll reduce the risk of merge conflicts in future backport PRs

Thanks@erlend-aasland for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11, 3.12.
🐍🍒⛏🤖

GH-106444 is a backport of this pull request to the3.12 branch.

GH-106445 is a backport of this pull request to the3.11 branch.

I intentionally made this file having extension different from.c, soclinic.py --make will not regenerate it.

It makes regenerating it inconvenient, but on other hand, it prevents unintentional regeneration. Otherwise the breaking changes in clinic.py can pass unnoticed, becausemake clinic is ran before clinic tests.

There was consensus on the core dev Discord for this change.

Ideally, I would like to get rid of clinic.test.c, and move all those test to _testclinic.c, to make sure the generated code actually works as expected in Python.

It makes regenerating it inconvenient, but on other hand, it prevents unintentional regeneration. Otherwise the breaking changes in clinic.py can pass unnoticed, becausemake clinic is ran before clinic tests.

IMO, a better option is to add an--exclude option to the clinic CLI and explicitly exclude that file when runningmake clinic.

See#107770 for my suggestion to preservemake clinic behaviour.

Initially I introducedLib/test/clinic.test as a temporary solution, because I was not very familiar with the AC code and did not know how to use it programmatically to generate only an interesting part of output (I still does not know this).clinic.test contains a lot of generated noise unrelated to a purpose of specific test. For example all these ugly struct initializers for_kwtuple and_parser take too much space.

My hope is that someday someone (maybe you, maybe me) will turn most or all of these tests into proper unit tests.

It sounds to me that your intention harmonises with my desire to turnclinic.test.c into functional tests. So we agree, I think.