Increase stack size for build.rs to prevent overflow on Windows

[lifthrasiir]

This pull request modifies the build script in pyre/pyre-jit-trace/build.rs to address stack overflow issues during parsing on Windows. The main change is running the build logic on a worker thread with an increased stack size to prevent overflows when parsing many source files.

Build process robustness:

• The build logic is now executed on a worker thread with a 64 MiB stack, instead of the main thread, to avoid stack overflows caused by deep recursion during parsing with syn on Windows. The actual build logic has been moved to a new real_main function.

Summary by CodeRabbit

• Bug Fixes
  • Improved build system stability to prevent build failures during large-scale source code compilation.

[coderabbitai]

Walkthrough

The build script is refactored to execute the build pipeline on a dedicated worker thread configured with 64MiB stack size. The new main() spawns real_main() on the worker thread and waits for completion, preventing stack overflow during recursive source file parsing. All build logic remains unchanged semantically.

Changes

Build Thread Stack Overflow Prevention

Layer / File(s)	Summary
Thread Configuration and Refactoring pyre/pyre-jit-trace/build.rs	main() spawns real_main() on a worker thread with 64MiB stack via std::thread::Builder, joining and propagating thread errors. Prior build logic is moved into real_main() without semantic change.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A bunny's build now stands up tall,
With 64 megs to heed the call,
No stack shall overflow, no more the fright,
Threading deep through parsing night! ✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: moving build.rs execution to a worker thread with increased stack size to fix Windows stack overflow issues.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@pyre/pyre-jit-trace/build.rs`:
- Around line 16-26: When rejoining the worker thread created by
std::thread::Builder::new().stack_size(...).spawn(real_main), avoid losing the
worker's original panic message by inspecting the Err payload from join()
instead of calling expect directly; on Err, downcast the Box<dyn Any + Send>
payload to &str or String (or format it generically) and re-panic with that
message (or call std::panic::resume_unwind with the original payload) so the
main-thread panic contains the worker's original diagnostic text and backtrace;
locate the join()/.expect("build-script worker panicked") call and replace the
expect with logic that downcasts and re-raises the original payload from the
join() result.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 6fae8fbf-fac7-4857-b5dd-0f538c05971f

📥 Commits

Reviewing files that changed from the base of the PR and between 9cdec64 and 54e3be9.

📒 Files selected for processing (1)

• pyre/pyre-jit-trace/build.rs

[coderabbitai]

🧹 Nitpick | 🔵 Trivial | 💤 Low value

Core change LGTM — optional: forward the worker's panic payload for cleaner build output.

The spawn/join pattern is correct: fn real_main satisfies FnOnce() + Send + 'static, the 64 MiB stack directly addresses the documented Windows overflow, and cargo::rerun-if-changed directives emitted from the worker thread reach Cargo correctly because stdout is process-wide and there is no concurrent output.

One cosmetic gap: when the worker panics, Rust's default panic hook already prints the message + backtrace to stderr before join() returns Err, so diagnostic information is preserved. However, the subsequent .expect("build-script worker panicked") emits a second, less-informative panic in the main thread. If you want the re-raised panic to carry the original message, you can downcast the payload:

♻️ Optional: re-raise worker panic payload in the main thread

-        .join()
-        .expect("build-script worker panicked");
+        .join()
+        .unwrap_or_else(|e| {
+            let msg = e
+                .downcast_ref::<&str>()
+                .copied()
+                .or_else(|| e.downcast_ref::<String>().map(|s| s.as_str()))
+                .unwrap_or("<non-string panic payload>");
+            panic!("build-script worker panicked: {msg}");
+        });

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	// Run on a worker thread with a large stack: on Windows the main
	// thread's default stack is 1 MiB, which `syn`'s recursive parsing
	// of the ~90 collected source files overflows
	// (STATUS_STACK_OVERFLOW 0xc00000fd).
	std::thread::Builder::new()
	.stack_size(64 * 1024 * 1024)
	.spawn(real_main)
	.expect("spawn build-script worker")
	.join()
	.expect("build-script worker panicked");
	}
	// Run on a worker thread with a large stack: on Windows the main
	// thread's default stack is 1 MiB, which `syn`'s recursive parsing
	// of the ~90 collected source files overflows
	// (STATUS_STACK_OVERFLOW 0xc00000fd).
	std::thread::Builder::new()
	.stack_size(64 * 1024 * 1024)
	.spawn(real_main)
	.expect("spawn build-script worker")
	.join()
	.unwrap_or_else(|e| {
	let msg = e
	.downcast_ref::<&str>()
	.copied()
	.or_else(|| e.downcast_ref::<String>().map(|s| s.as_str()))
	.unwrap_or("<non-string panic payload>");
	panic!("build-script worker panicked: {msg}");
	});
	}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@pyre/pyre-jit-trace/build.rs` around lines 16 - 26, When rejoining the worker
thread created by std::thread::Builder::new().stack_size(...).spawn(real_main),
avoid losing the worker's original panic message by inspecting the Err payload
from join() instead of calling expect directly; on Err, downcast the Box<dyn Any
+ Send> payload to &str or String (or format it generically) and re-panic with
that message (or call std::panic::resume_unwind with the original payload) so
the main-thread panic contains the worker's original diagnostic text and
backtrace; locate the join()/.expect("build-script worker panicked") call and
replace the expect with logic that downcasts and re-raises the original payload
from the join() result.