Open in StackBlitz

npm i https://pkg.pr.new/rescript-lang/rescript@7913

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

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

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

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

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/runtime@7913

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

commit:64b3b83

CODEX review:

The new clause incompiler/core/lam_pass_remove_alias.ml:87 skips thePis_not_none guard whenever the metadata says we have a constantSome. That’s fine for well-behaved values, but it removes the last runtime check that protects the non-nested option encoding from strayundefineds. Before this change, constants showed up inLam_stats asConstant, so we kept emittingfoo !== undefined ? … : …; with the new shortcut we collapse directly to theSome arm.

You can see the behavioural change with a tiny repro that smuggles anundefined payload throughObj.magic (something we allow today for interop):

letfoo:option<int>=Obj.magic(Some(Obj.magic(None:option<int>)))letres=switchfoo {  |Some(_)=>"some"  |None=>"none"  }Js.log(res)

• Building the compiler before this patch still outputs code that performsfoo !== undefined at runtime, so it prints "none" when the payload is actuallyundefined.
• After this patch lands, the generated JS becomeslet res = "some";, so the same program now prints "some".

I verified this by locally reverting the newConstant c branch, rebuilding (make), and comparing the generatedtmp_magic_weird.js/cjs. The regression only reproduces once the new shortcut is present.

Could we gate the optimisation onLam_constant.is_some_none_aux (i.e. ensure we’re not in the non-nested encoding with anundefined payload), or fall back to the old behaviour when the payload can beundefined?

CODEX follow-up:

You’re absolutely right—the simplified JS (let res = "some";) was already produced before this patch. I rebuilt the parent commit to double-check and confirmed that I’d misread the before/after comparison. Sorry for the noise!

However, the report is legit in a wider sense.
It opens a question of what we want to do with incorrect types coming from obj magic or incorrect externals.
I think we need a clear position on that.

However, the report is legit in a wider sense. It opens a question of what we want to do with incorrect types coming from obj magic or incorrect externals. I think we need a clear position on that.

I think with incorrect externals, all bets are off.