gh-109287: fix overrides in cases generator

[carljm]

The fix here is based on fully buying into the idea that inst is just syntactic sugar for an op and macro, and the principle that one does not ever override a macro, one overrides only the definition of an op; override inst is equivalent to override op. One can freely override an op (whether originally defined via op or implicitly via inst) that may be part of one or several macros (explicit or implicit), and the override will be reflected in the generated contents of each macro.

I think this approach makes sense; since explicitly-defined macros have never supported overrides, it's not clear why we should try to special-case some concept of overriding implicitly-defined macros.

I also think this approach should meet all our actual override needs; if we discover that I'm wrong, we can propose a later PR to generally add support for macro overrides.

This also implies some behavioral changes. The idea of a "placeholder comment" for overrides, or trying to emit the override contents later in the output, no longer makes much sense, since ops do not directly appear in the output, only macros do, and the macro itself is not overridden.

We could add an "// override" comment in some form; I didn't do that here and don't think it's needed. If you are trying to debug why your generated cases look the way they do, you should be enabling #line directives, which will give you much clearer provenance details.

• Issue: Transform inst(X, ...) to op(X, ...) plus macro(X) = X in code generator #109287

[carljm]

I will be mostly unavailable from Oct 6 to Nov 4; if this isn't merged by Oct 6 reviewers should feel free to edit as needed and merge.

[gvanrossum]

Good riddance to OverriddenInstructionPlaceHolder!

Two interesting facts:

• If you override an inst with an op, you still get a macro with the same name; but if you override an op with an inst you don't. I think that's fine (the latter case is odd anyway).
• Overrides are now replacing the original instruction in the output rather than being appended at the end.

Agreed that for debugging, --emit-line-directives is the way to go.

[carljm]

Yeah I was aware of the second point and think it's fine. I hadn't thought about the first point; we could make it an error but I also think it's fine, the behavior you get is not unreasonable.

[gvanrossum]

Yeah it’s all fine.

[bedevere-bot]

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot aarch64 RHEL8 LTO 3.x has failed when building commit 3c0f65e.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/338/builds/5269) and take a look at the build logs.
4. Check if the failure is related to this commit (3c0f65e) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/338/builds/5269

Failed tests:

• test_interpreters

Summary of the results of the build (if available):

==

Click to see traceback logs

Note: switching to '3c0f65ebce10d5327e07245f7cf2beb96b18c970'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 3c0f65ebce gh-109287: fix overrides in cases generator (#110419)
Switched to and reset branch 'main'

make: *** [Makefile:2020: buildbottest] Error 5