Limit `Failed to match` messages to code annotations

[disinvite]

The functions that try to match orig and recomp entities will report error messages like Failed to match function at 0x1234 with name 'Hello' if we try to find an orig entity with the given name but came back empty. This made sense when it was only possible to provide metadata for orig entities via the code annotations.

If you are providing metadata via CSV or (in the future) from a PDB or MAP file that belongs to the original program, we should not report a failed match. The message isn't useful because the orig metadata would be more comprehensive than the recompiled code until the completion of the decomp.

[disinvite]

With some more thought on this... is the message useful at all?

Why would we fail to match a name or symbol lookup?

• There is an original entity with no corresponding recomp entity
• There is a recomp entity with no corresponding orig entity

In the first case (what the Touhou team encountered), if your metadata exceeds the implemented functions, there isn't a need to report this. What we could do (in combination with #343) is add orig-only entities to the report, perhaps as stubs. That way you would see everything from the original address space and could target implementing stubs as a "TODO list".

In the second case, you may simply have extra functions on the recomp side. For example: if the compiler chose to inline a function or not, or if you are building multiple targets and not excluding compatibility functions with a preprocessor directive.

For line-based annotations (i.e. //FUNCTION above the implementation) we already have an alert if we detect the PDB is out of sync with the code, either due to compiler inlining or a code change without a recompile.

If you are not using line-based annotations, renaming a function (e.g. from FUN_12345678 to its final name) will break the connection to any metadata. But if you are using the --diff option locally or in your CI, you should see these dropped functions and new diffs pretty clearly without the need for a second alert.

[jonschz]

Without having given too much thought on this, I'd prefer to keep the functionality lean and not optimise every single edge case. If you have a decent argument that the log message is not helpful, I'd rather remove it than to fine-tune its behaviour.

[disinvite]

I think the real issue here (and my reason for not acting on this yet) is that errors are good when we see only a few (or zero), and bad otherwise.