Fix execute_code failing on the BOM-only CodeDom error#1192
Conversation
On Mono, mcs emits a stray UTF-8 BOM line on stdout. CodeDom can't parse it, so it fabricates an error that has no error number and whose text is just the BOM, then refuses to return the compiled assembly — even though mcs exited 0 and wrote the DLL. Users see this as a spurious "Line 1: " compilation failure (CoplayDev#1186). Compile to a temp DLL on disk instead of in-memory, skip the content-less BOM "error" while still surfacing real compiler errors, and Assembly.Load the DLL that mcs actually produced. The temp DLL is cleaned up in a finally block.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe ChangesCodeDom Disk-Based Compilation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
1 participant
Description
execute_codeintermittently fails with a spurious"Line 1: "compilation erroreven when the submitted code is valid. This fixes that false negative.
On Mono,
mcsemits a stray UTF-8 BOM line on stdout. CodeDom can't parse it, so itfabricates an error that has no error number and whose text is just the BOM, then refuses
to return the compiled assembly — even though
mcsexited 0 and wrote the DLL. Users seethis as a spurious
"Line 1: "compilation failure (#1186).Type of Change
Changes Made
GenerateInMemory = false+OutputAssembly) instead of in-memory.BOM/whitespace) while still surfacing every real compiler error exactly as before.
Assembly.Loadthe DLL thatmcsactually produced, and clean the temp file up in afinallyblock.Stripping the BOM from the input (as suggested in #1186) doesn't help, because the BOM comes
from the compiler's own stdout, not the source. Going through a real output assembly lets us tell
"the compiler emitted junk on stdout" apart from "the code didn't compile": if there are no real
errors and a DLL exists on disk, we load it.
Compatibility / Package Source
#beta,#main, tag, branch, orfile:):file:(local package)Packages/packages-lock.json(if using a Git package URL): N/A (localfile:package)Testing/Screenshots/Recordings
cd Server && uv run pytest tests/ -v)Documentation Updates
tools/UPDATE_DOCS_PROMPT.md(recommended)Related Issues
Fixes #1186
Additional Notes
Single-file change (
MCPForUnity/Editor/Tools/ExecuteCode.cs), no tool/resource surface changes, so no docs update needed.Not unit-tested in CI: the failure depends on the host Mono
mcsemitting a BOM on stdout, whichisn't reproducible from a pure EditMode test. Verified manually — reproduced #1186 (valid snippet
returning
"Line 1: "), confirmed it now executes, and confirmed genuinely broken code stillreports the real compiler errors.
Summary by CodeRabbit