Bound how deep inlining nests

[cknitt]

When Lam_pass_remove_alias inlines a call to a small function, it simplifies the inlined body again, which can inline the functions that body calls, and so on. Each step passes the size check, because it only looks at the callee's original body, but nothing bounded the nesting. In a chain of small functions that each call the previous one, every function got the whole chain inlined:

let f0 = x => x + 1
let f1 = x => f0(x) + 1
let f2 = x => f1(x) + 2
// ...

// f39 before
function f39(x) {
  return ((((((x + 1 | 0) + 1 | 0) + 2 | 0) /* ... 36 more */ + 39 | 0;
}

So both the generated code and compile time grew quadratically with the length of the chain.

Nested inlining now stops at depth 4; beyond that the compiler emits a call. Functions marked @inline are exempt, and functor inlining is unchanged.

The limit is a safety bound against this blowup, not a code-size optimization. I compiled all test sources, Belt and the benchmark inputs (662 files) with limits 1 to 4:

• Limits 2, 3 and 4: the output is identical to master.
• Limit 1: it already changes one existing test.

4 leaves more room than needed for existing code while keeping the worst case linear.

Chain of N small functions	Before	After
1,000	1.9s	107ms
4,000	32.8s	346ms
8,000	—	713ms

New test: inline_chain_test.res checks a chain of small functions and a chain of @inline functions at runtime. Its checked-in JS pins that the former stops inlining after four levels and the latter is still fully inlined.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LFDffswgCJNtcpW4vKw6et

[cknitt]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-11T19:44:12.019186Z	1557d40	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Bravo.

Reviewed commit: 1557d40de2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.40%. Comparing base (98beeb5) to head (eb153d4).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #8801   +/-   ##
=======================================
  Coverage   80.40%   80.40%           
=======================================
  Files         447      447           
  Lines       60984    60990    +6     
=======================================
+ Hits        49036    49042    +6     
  Misses      11948    11948           

Files with missing lines	Coverage Δ
compiler/core/lam_pass_remove_alias.ml	83.48% <100.00%> (+0.96%)	⬆️

🚀 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.

[pkg-pr-new]

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript@8801

@rescript/belt

npm i https://pkg.pr.new/@rescript/belt@8801

@rescript/darwin-arm64

npm i https://pkg.pr.new/@rescript/darwin-arm64@8801

@rescript/darwin-x64

npm i https://pkg.pr.new/@rescript/darwin-x64@8801

@rescript/linux-arm64

npm i https://pkg.pr.new/@rescript/linux-arm64@8801

@rescript/linux-x64

npm i https://pkg.pr.new/@rescript/linux-x64@8801

@rescript/runtime

npm i https://pkg.pr.new/@rescript/runtime@8801

@rescript/win32-x64

npm i https://pkg.pr.new/@rescript/win32-x64@8801

commit: eb153d4

[cristianoc]

@cknitt What's your view on the trade-off between smaller generated code and runtime performance with the depth limit? Do you expect the extra calls to have a noticeable runtime cost?

[github-actions]

Developer playground preview: https://rescript-lang.github.io/rescript/dev-playground/?version=pr-8801

[cknitt]

@cristianoc For the examples/tests in the compiler repo, no output diff is observed withmax_inline_depth = 2. Same in a large project of ours that I have tested with.

Still, I am open to a less strict max, what value would you suggest?

[cristianoc]

@cristianoc For the examples/tests in the compiler repo, no output diff is observed withmax_inline_depth = 2. Same in a large project of ours that I have tested with.

Still, I am open to a less strict max, what value would you suggest?

Not sure. So far it points to removing the concept entirely.
Until it makes actual difference.

[cristianoc]

Will let you deal with tradeoffs and decide which way to go.

[cknitt]

Decided to go ahead with a limit of 4.

With 4, the 4,000-function chain compiles in 0.35s (0.29s with 2, 33s without a limit).