fix(webview2): fixed the generator, not its output — nine COM marshalling families

[13thgoutham]

pkg/webview2 is unusable as shipped on amd64: importing it panics during package init. #36 fixes that in three lines. This PR is what I found when I went looking for why.

The committed pkg/webview2 is not the output of the committed generator. Defects here have been fixed by sweeping the 306 generated files — fix: com error handling and fix: mischanged error values between them touched 800+ call sites — and never the templates that produce them. So every regeneration silently reverts every fix. I did that regeneration to check, and 174 files came back changed.

So this fixes the generator and commits the regeneration. Nine families, and they share a failure mode that is worth stating plainly, because it is why none of them was ever caught by review: the wrong code compiles, links, runs and returns S_OK.

family	sites	what the generated code did
vtable inheritance	88 interfaces	derived vtables embedded IUnknownVtbl instead of the base's vtable, so every method sat too early. ICoreWebView2_14.AddServerCertificateErrorDetected dispatched at slot 4 — ICoreWebView2::get_Settings — instead of 107, and get_Settings has one out-parameter, so it wrote the Settings pointer over the caller's event-handler struct and returned S_OK
by-value in-params	~166	the type switch compared the IDL type ("BOOL", "INT32") against Go type names, so it matched almost nothing and everything fell through to &address. Includes all 61 remove_* event tokens: each passed the address of the 8-byte token it was supposed to match, so no event handler could ever be removed
string out-params	109	LPWSTR* out-params passed the local's nil value rather than its address, so the callee had nowhere to write and every string getter returned ""
QueryInterface accessors	56 of 82	rooted on ICoreWebView2 regardless of which object implements the interface, so GetICoreWebView2Controller2 asked a webview for a controller interface and could only fail, while ICoreWebView2Controller had no accessor at all
Call's Errno as error	all	the third result of ComProc.Call is a syscall.Errno that is non-nil on success, so every successful call looked like a failure. IUnknown::Release's refcount was discarded the same way
float in-params	12	passed a Go float's address where the callee reads a register. Fixable on amd64: Go's syscall assembly copies each of the first four argument slots into the matching XMM register, precisely so this works
32-bit out-params	7	INT/UINT/int mapped to Go's 64-bit int/uint, so a 4-byte write left the high half zero and the sign never extended — GetExitCode returned 3221225477 for -1073741819
struct field widths	1 type	a struct field's BOOL generated as Go's 1-byte bool, making COREWEBVIEW2_PHYSICAL_KEY_STATUS 12 bytes against a native 24. GetPhysicalKeyStatus passes that local's address, so every call wrote 12 bytes past the end of a heap object, and three of the four flags were read from padding
callback widths	3	LPCWSTR result declared as a Go string; NewCallback rejects anything wider than a uintptr and does so when the callback is constructed, which happens in a package-level var — hence the import-time panic in #36

Verified on Windows, not just reasoned about

This is the part I would want if I were reviewing it. Marshalling bugs are invisible to review and to go build, so the PR adds a way to execute them.

A COM object is a pointer to a table of function pointers, so one can be built entirely out of Go: fill a generated Vtbl with NewComProc(someGoFunc) and hand its address to the generated wrapper. The wrapper marshals exactly as it would for real WebView2 and the fake callee sees what actually arrived.

It needs no WebView2 Runtime, no Edge, no display and no network — Windows and nothing else, so windows-latest is enough. Ten tests, one per argument shape, all passing on a real Windows 11 machine:

=== RUN   TestBoolInParamArrivesByValue
--- PASS: TestBoolInParamArrivesByValue (0.00s)
...
=== RUN   TestHResultDecidesTheError
--- PASS: TestHResultDecidesTheError (0.00s)
PASS

The generator side gains property tests over the whole surface rather than goldens for one interface — every derived vtable embeds its declared base; every interface's vtable declares exactly the methods the IDL declares (252/252, which is the half of the slot-offset argument that embedding alone does not establish); no callback parameter exceeds a register; Call's Errno is never returned; and — the one nothing checked before — the committed pkg/webview2 is the generator's output. That last test is what stops this regressing the same way again, and it is verified to go red when a generated file is hand-edited.

API changes, called out rather than buried

• CallRelease and IStream.Release return uint32 (the refcount) instead of error.
• Seven getters return int32/uint32 instead of int/uint. They returned wrong values before.
• COREWEBVIEW2_PHYSICAL_KEY_STATUS's flag fields are int32 instead of bool — required to match the native 24-byte layout.
• 56 QueryInterface accessors move onto the object that can answer them. The ICoreWebView2_N family stays on ICoreWebView2, so callers of those are unaffected.
• Release() is now generated alongside AddRef() on the 170 non-handler interfaces. QueryInterface AddRefs, so every accessor call previously leaked a reference with nothing to call. Additive.

Things left broken, deliberately

• Array-valued parameters have no representation. GetAllowedOrigins returns *string for an LPWSTR** array, so dereferencing the result builds a Go string header out of a pointer array — an unbounded read, not a wrong value. Same shape for Get/SetCustomSchemeRegistrations. Fixing it needs a slice concept and an ownership decision, which is an API call for a maintainer rather than a marshalling fix. Arguably these four methods should not be emitted at all until then.
• Float in-params on windows/arm64. sys_windows_arm64.s loads R0–R7 and never V0–V7, carrying a TODO to do what amd64 does. Passing the bits in an integer register is no worse there than passing a pointer was, so this is a strict improvement on both, but arm64 is not correct.
• CoTaskMemFree is skipped when a method returns early on a failed HRESULT; only a callee that allocates and then fails leaks, which is a contract violation.
• != windows.S_OK rejects other success codes; S_FALSE appears in none of the six IDLs in scripts/.

Reviewing this

The 174 changed files under pkg/webview2 are machine output — cd scripts && go run ./regen -idl WebView2.1.0.2903.40.idl -out /tmp/x && diff -r /tmp/x ../pkg/webview2 is empty. The reviewable change is the 29 files under scripts/, and the three commits separate it cleanly: the generator, then the tests, then the regeneration on its own so it can be skipped in review and reproduced instead.

Worth one sanity check if you want it: that regeneration is byte-identical whether the generator runs on this base or on a tree that had all nine families patched by hand. The output is derived, so the base does not matter — which is the whole argument for fixing the generator rather than its output.

scripts/regen is new and is what makes any of this checkable: update_version_mapping.go only regenerates as a side effect of finding a NEW version upstream, needs the network, and rewrites the tree in place, so there was no way to regenerate a pinned IDL and diff it. That is why the drift went unnoticed for so long.

A GitHub Actions workflow running all of the above — the marshalling tests on windows-latest, the generator's tests and a cross-compile on ubuntu-latest — is ready and deliberately not in this PR, since adding a workflow is a maintainer's call rather than a contributor's. Say the word and I will add it.

On #36: this fixes that bug at its root (family 9) but does not contain #36's commit, so the two do not conflict. #36 remains the version you can merge in ten seconds if you want the package importable now and would rather take this one slowly — I would suggest exactly that.