Repository navigation
fix(execute_code): alias Object and Random to UnityEngine; hint at Roslyn when CodeDom fails - #1455
MohammediYunus wants to merge 1 commit into
Conversation
The execute_code wrapper imports both System and UnityEngine, so a bare Object or Random was an ambiguous reference (CS0104) under both CodeDom and Roslyn. Snippets like Object.DestroyImmediate(go) or Random.Range(0, 10) never compiled. - Add `using Object = UnityEngine.Object;` and `using Random = UnityEngine.Random;` to the wrapper. The `object` keyword still means System.Object, and System.Random still works when written out. - Bump WrapperLineOffset from 10 to 12 so compiler errors keep pointing at the user's own lines (used by both the CodeDom and Roslyn paths). - When a CodeDom compile fails, add a `hint` to the error data: point at the Roslyn row in the MCP for Unity window, or suggest compiler='auto' when codedom was forced and Roslyn is already installed. - Document the aliases in the tool description, the generated reference page and both skill copies.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to The alias and compiler-guidance changes appear ready to merge after normal checks. Pre-merge checks |
  |
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 18.18% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 11 functions across 3 files. (3 skipped: … | Write docstrings for the functions missing them to satisfy the coverage threshold. |
✅ Passed checks (4 passed)
-
Check name Status Explanation Title check The title clearly summarizes the two primary changes: UnityEngine aliases for Object and Random, and Roslyn guidance when CodeDom compilation fails. Description check The description follows the repository template and provides complete change details, compatibility information, testing results, documentation updates, and the related issue. Linked Issues check Direct issue [ #1439] requires a UnityEngine.Object alias and a CodeDom failure hint. ExecuteCode.cs adds the wrapper aliases, sets WrapperLineOffset to 12, and returns hints for forced CodeDom and aut…Out of Scope Changes check The changes remain connected to [ #1439]. The Random alias addresses the same System and UnityEngine name collision in the same execute_code wrapper. The line-offset update, regression tests, tool desc…
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 18.18% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 11 functions across 3 files. (3 skipped: 3 unsupported.)
- Fix all pre-merge checks with AI
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This branch has not been deployed
2 participants
Description
execute_codewraps every snippet in a class that imports bothSystemandUnityEngine. That makes a bareObjectorRandoman ambiguous reference (CS0104), so everyday snippets likeObject.DestroyImmediate(go),Object.FindObjectsByType<Camera>(...)andRandom.Range(0, 10)fail to compile. It isn't only a CodeDom thing: Roslyn rejects them too, because the ambiguity comes from the wrapper's ownusinglines.This adds two aliases to the wrapper:
The
objectkeyword still meansSystem.Object, andSystem.Randomstill works when you write it out.WrapperLineOffsetgoes from 10 to 12 so compile errors keep pointing at the user's own lines. Both the CodeDom and the Roslyn paths use that constant.For the second half of #1439, a failed CodeDom compile now includes a
hintin the error data. I didn't say "C# 6" in the hint because Unity's mcs actually accepts C# 7 tuples andis int npatterns. The clear failures start at C# 8 (switch expressions,??=,is not), so the hint names those. It points at the Roslyn row in the Dependencies section of the MCP for Unity window, which is where the installer lives now. Ifcompiler='codedom'was forced while Roslyn is already installed, it suggestscompiler='auto'instead.Aliasing
Randomgoes a step past what the issue asked for. It's the same CS0104 problem, so I included it, but I'm happy to drop it and keep this toObjectonly if you'd prefer.Before and after
Same snippet,
compiler="auto"with no Roslyn installed (so CodeDom):Before (beta 142ea0a):
After:
success: true,result: true.Real
execute_coderesponses in Unity 6000.3.24f1, before and after, with each backend ("Roslyn" means the Roslyn DLLs were inAssets/Plugins/Roslynandcompiler="auto"):Object.DestroyImmediate(go)Object.FindObjectsByType<Camera>(...)Random.Range(0, 1)new System.Random(1).Next(1)object o = 1; return o is int;Example hint, CodeDom forced while Roslyn is installed:
Type of Change
Changes Made
ExecuteCode.cs: two alias lines inWrapUserCode,WrapperLineOffset10 to 12 with a note that it must match the header length, and ahintfield on the two CodeDom failure returns (forcedcodedomand theautofallback). The Roslyn paths and theroslyn-not-available message are unchanged.ExecuteCodeTests.cs: each case runs withcodedomand withauto:Object.DestroyImmediateRandom.RangeobjectplusSystem.Randomstill compilingautopicks Roslyn.execute_code.py: one sentence in the tool description sayingObjectandRandomresolve to the UnityEngine types. The reference page is regenerated, and both skill copies oftools-reference.mdgot the same edit.Compatibility / Package Source
file:(the TestProjects/UnityMCPTests setup)Packages/packages-lock.json: n/a (file:package)No behaviour change for code that already writes
UnityEngine.ObjectorSystem.Randomin full, or that uses theobjectkeyword. A bareObjectorRandomcouldn't compile before, so snippets that work today keep working. There's one edge case I found while testing: a project with its own class namedRandomorObjectin the global namespace. A snippet that used that class by its bare name used to bind to it and now gets CS0576.global::Randomstill reaches it, and snippets that don't use the name aren't affected.To get .NET's random number generator, write
new System.Random(seed). A barenew Random(42)was CS0104 before and is CS0712 now (UnityEngine.Random is static), so it's a compile error either way.The test code only uses APIs that exist back to 2021.3 (
GameObject,Object.DestroyImmediate,Random.Range). I couldn't run the 2021.3, 2022.3, 6000.0 or 6000.4 editors locally, so the floor compile is down tocompile-check.yml.Testing/Screenshots/Recordings
cd Server && uv run pytest tests/ -v)All on Unity 6000.3.24f1 in batchmode (
-batchmode -nographics -runTests -testPlatform EditMode):ExecuteCodeTestson beta with only the new tests added: 36 passed, 6 failed (the alias and hint cases). The line-3 test passes on beta too, since 10 is right for the old header.ExecuteCodeTestswith this change: 42/42 under CodeDom, and 42/42 again with Roslyn inAssets/Plugins/Roslyn, soautouses Roslyn.Execute_CompilationError_ReportsUserLineNumberfails for both cases ("Line 5" instead of "Line 3").Server side:
uv run pytest tests/ -v: 1575 passed, 18 skipped.uv run python -m pytest tools/tests/: 205 passed.tools/generate_docs_reference.py --check: up to date.tools/check-unity-versions.sh: ran, but all four matrix versions were skipped because none of them are installed here.Documentation Updates
tools/UPDATE_DOCS_PROMPT.md(recommended)Only the description changed. I regenerated the reference page with
tools/generate_docs_reference.pyand made the same one-phrase edit in both skill copies.Related Issues
Fixes #1439
Additional Notes
I left the
roslyn-not-available message alone and kept the offset as a constant, so the change stays small and the new line-number test guards it.Summary by CodeRabbit
Bug Fixes
ObjectandRandomin C# code execution now resolve to their Unity types; useSystem.Randomto access .NET’s random number generator.Improvements
Documentation