Fix CodeMatch.Calls to match Newobj opcode and add ConstructorInfo overload

[Copilot]

CodeMatch.Calls(MethodInfo) only matched Call/Callvirt opcodes, not Newobj, contradicting XML docs that claimed constructor support. No API existed to match constructors by ConstructorInfo.

Changes

Opcode matching

• Replace opcodesCalling with opcodesCallingOrNewobj (Call, Callvirt, Newobj)
• Apply to all Calls methods and expression-based CodeMatch constructors

New overloads

• CodeMatch.Calls(ConstructorInfo)
• CodeMatch.Calls(MethodBase)
• CodeInstruction.Calls(ConstructorInfo) extension

Documentation

• All Calls methods now explicitly document matched opcodes and null behavior

Binary compatibility

Original Calls(MethodInfo) signature preserved. New overloads are purely additive—existing compiled code works without recompilation.

Usage

// Match constructor
var ctor = typeof(MyClass).GetConstructor([typeof(int)]);
matcher.MatchStartForward(CodeMatch.Calls(ctor));

// Extension method
if (instruction.Calls(ctor)) { ... }

// Match any call/newobj (wildcard)
matcher.MatchStartForward(CodeMatch.Calls((MethodInfo)null));

Original prompt

---

This section details on the original issue you should resolve

<issue_title>CodeMatch.Calls(MethodInfo) does not match constructors despite XML docs/summary claiming it does</issue_title>
<issue_description>Describe the bug
CodeMatch.Calls(MethodInfo) does not accept a ConstructorInfo/MethodBase, nor does it check for the Newobj opcode.

This contradicts the XML docs/summary, which states that it tests for a constructor.

Harmony/Harmony/Tools/CodeMatch.cs

Lines 195 to 199 in d0ebd09

	/// <summary>Tests if the code instruction calls the method/constructor</summary>
	/// <param name="method">The method</param>
	/// <returns>A new code match</returns>
	///
	public static CodeMatch Calls(MethodInfo method) => WithOpcodes(CodeInstructionExtensions.opcodesCalling, method);

CodeMatch.Calls uses opcodesCalling, which only includes Call and Callvirt opcodes.

To Reproduce
Situation 1 (matching any call):

1. Create a CodeMatcher
2. Call one of the matching methods while passing CodeMatch.Calls((MethodInfo)null)
3. The matcher will only match Call and Callvirt opcodes, ignoring any Newobj opcodes

Situation 2 (matching specific constructor):

1. Create a CodeMatcher
2. Get a ConstructorInfo object
3. Call one of the matching methods while passing CodeMatch.Calls(constructorInfo)
4. Code cannot compile as there's no matching method signature

Expected behavior
I've expected that either of those 2 would be true:

• CodeMatch.Calls summary does not mention testing for a constructor
• CodeMatch.Calls accepts MethodBase/ConstructorInfo (possibly as an overload) and matches Newobj opcode

Screenshots / Code
The following code will go through all instructions and log all matches for CodeMatch.Calls (with null as argument). It'll log every instruction using Call and Callvirt opcodes, but none using Newobj opcodes.

var matcher = new CodeMatcher(instr);
while (true)
{
    matcher.MatchEndForward(CodeMatch.Calls((MethodInfo)null));
    if (matcher.IsValid)
        Console.WriteLine($"{matcher.Instruction}");
    else
        break;
    matcher.Advance();
}

Runtime environment (please complete the following information):

• OS: Windows 10, 64bit
• .NET Framework 4.8
• Harmony version 2.4.1
• Name of game or host application: RimWorld
  </issue_description>

<agent_instructions>Do an analysis of this issue. Only start changing code if it 100% clear that there is exactly one way to solve this and no questions are left. Otherwise, generate a report on things that need more feedback.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes CodeMatch.Calls(MethodInfo) does not match constructors despite XML docs/summary claiming it does #758

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[pardeike]

@copilot We changed a few areas of the code so I want you to think general and find uses we missed. Something that would make sense and would keep things in symmetry function-wise. I want to avoid adding features that only solve part of the problem they touch. Do not edit code but just work out what we might have been overlooking related to the context this PR and its original Issue is about.

[Copilot]

@copilot We changed a few areas of the code so I want you to think general and find uses we missed. Something that would make sense and would keep things in symmetry function-wise. I want to avoid add...

Here's my analysis of potential gaps and related areas:

1. CodeInstructionExtensions.Calls(MethodInfo) extension method (Extensions.cs:510)
This is the most significant oversight. There's an extension method CodeInstruction.Calls(MethodInfo) that has identical documentation claiming it "tests for method/constructor" but only checks Call/Callvirt, not Newobj. This should be updated similarly and also get a ConstructorInfo overload.

2. Dead code: opcodesCalling (Extensions.cs:210)
The original opcodesCalling HashSet is now unused - all references were replaced with opcodesCallingOrNewobj. Consider removing it unless you want to keep it for potential backward compatibility if anyone was using it directly (though it's marked internal).

3. Missing MethodBase overload
Since MethodBase is the common base class of both MethodInfo and ConstructorInfo, adding a Calls(MethodBase) overload would provide maximum flexibility for users who already have a MethodBase reference.

4. Expression-based constructors
The CodeMatch(Expression<Action>) and CodeMatch(LambdaExpression) constructors were updated to use opcodesCallingOrNewobj, but they use SymbolExtensions.GetMethodInfo() which may not work with constructor expressions. Worth verifying this path is tested or documenting limitations.

5. Code.Call vs Code.Newobj in the Code class
Users of Code.Call[myMethod] vs Code.Newobj[myConstructor] have separate explicit opcodes, which is correct. No change needed here.

The priority should be #1 (the extension method) as it has the same documentation/behavior mismatch as the original issue.