cl: fix TestGoptLambdaError

[xushiwei]

#2763

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.38%. Comparing base (828f29a) to head (b206439).
⚠️ Report is 13 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2768      +/-   ##
==========================================
+ Coverage   94.36%   94.38%   +0.02%     
==========================================
  Files          32       32              
  Lines       10486    10488       +2     
==========================================
+ Hits         9895     9899       +4     
+ Misses        421      420       -1     
+ Partials      170      169       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gemini-code-assist]

Code Review

This pull request updates cl/expr.go to return a "not type" error when resolving the first argument of a call fails, and enables the TestGoptLambdaError test in cl/typeparams_test.go. The review feedback correctly points out that unconditionally overriding the error with a generic "%v not type" message discards more specific and helpful compiler errors (such as undefined variables). It is recommended to preserve these specific errors while falling back to the generic message for other cases.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[fennoai]

Summary

This is a small, focused fix: when the first type argument in a typeAsParams call fails tryType, the compiler now returns a clear positioned error (%v not type) instead of silently breaking and proceeding with incomplete type inference. The re-enabled test (TestGoptLambdaError) confirms the new error message. The change is correct and safe for the case it handles.

Two findings worth noting before merge.

---

i > 0 failures still silently break — asymmetry is undocumented

The new guard only fires when i == 0. When a later type argument (i > 0) fails tryType, the code still silently breaks: m = len(targs) counts only the successfully resolved prefix, the remaining type params are padded with tp.At(i), and vargs = vargs[m:] slices off the prefix. This produces a confusing instantiation/inference error downstream rather than a clear "not type" diagnostic.

If the semantic intent is "a failure at position 0 means the call is definitively not in type-as-params form, so it is a hard error, while a failure at i > 0 means stop inferring and fall back", that reasoning should be captured in a comment — the asymmetry is non-obvious and a future reader is likely to "simplify" it incorrectly.

If i > 0 failures should also produce a clear error, generalize the guard to remove the i == 0 constraint.

---

Error message wording is grammatically awkward

"%v not type" (rendering as 100 not type) reads as an incomplete sentence. Standard Go compiler diagnostics use the form "X is not a type". Since this string is asserted verbatim in the test, now is the right time to align wording — e.g. "%v is not a type" — rather than freezing the current phrasing as a public diagnostic.

View job run

[fennoai]

When i == 0 fails, the compiler now hard-errors — but when i > 0 fails (a later type argument is not a type), the code still silently breaks and falls through to types.Instantiate with a partial targs slice, producing a confusing downstream error instead of a clear "not type" diagnostic.

If the intent is to only error when no type arguments have been resolved at all (i.e. the call is definitively not in type-as-params form), please add a comment explaining this reasoning — the asymmetry is non-obvious and likely to be 'fixed' incorrectly by a future reader. Otherwise, consider removing the i == 0 guard so all failing type-argument positions produce the same clear error.

[fennoai]

The error message "%v not type" renders as 100 not type, which is grammatically incomplete. Standard Go compiler diagnostics use "X is not a type". Since this string is asserted verbatim in TestGoptLambdaError, aligning the wording now (e.g. "%v is not a type") avoids freezing an awkward phrasing as a stable diagnostic.