Skip to content

Commit b9aad43

Browse files
committed
snapshot
1 parent 0fc514d commit b9aad43

File tree

3 files changed

+15
-9
lines changed

3 files changed

+15
-9
lines changed

lib/4.06.1/unstable/js_compiler.ml

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -110651,8 +110651,10 @@ module E = Js_exp_make
110651110651
Note if we inline {!Caml_exceptions.create},
110652110652
it seems can be useful for optimizations in theory,
110653110653
in practice, it never happen, since the pattern match
110654-
never dig into it internally, so maybe {!Obj.set_tag}
110655-
is not necessary at all
110654+
never dig into it internally.
110655+
Alternative is to create a block `["xx"]` which relies on object identity
110656+
We try to avoid this, since inlining would break this, this would make reason
110657+
about the correctness of inlining more difficult
110656110658
*)
110657110659
let make exception_str : J.expression =
110658110660
E.runtime_call Js_runtime_modules.exceptions Literals.create [exception_str]
@@ -395508,7 +395510,7 @@ let classify (prog : string) : Js_raw_info.exp =
395508395510
match Parser_flow.parse_expression
395509395511
(Parser_env.init_env None prog) false with
395510395512
| (_, Function {
395511-
id = None;
395513+
id = _;
395512395514
params = (_, {params});
395513395515
async = false;
395514395516
generator = false;

lib/4.06.1/unstable/js_refmt_compiler.ml

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -110651,8 +110651,10 @@ module E = Js_exp_make
110651110651
Note if we inline {!Caml_exceptions.create},
110652110652
it seems can be useful for optimizations in theory,
110653110653
in practice, it never happen, since the pattern match
110654-
never dig into it internally, so maybe {!Obj.set_tag}
110655-
is not necessary at all
110654+
never dig into it internally.
110655+
Alternative is to create a block `["xx"]` which relies on object identity
110656+
We try to avoid this, since inlining would break this, this would make reason
110657+
about the correctness of inlining more difficult
110656110658
*)
110657110659
let make exception_str : J.expression =
110658110660
E.runtime_call Js_runtime_modules.exceptions Literals.create [exception_str]
@@ -395508,7 +395510,7 @@ let classify (prog : string) : Js_raw_info.exp =
395508395510
match Parser_flow.parse_expression
395509395511
(Parser_env.init_env None prog) false with
395510395512
| (_, Function {
395511-
id = None;
395513+
id = _;
395512395514
params = (_, {params});
395513395515
async = false;
395514395516
generator = false;

lib/4.06.1/whole_compiler.ml

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -393245,8 +393245,10 @@ module E = Js_exp_make
393245393245
Note if we inline {!Caml_exceptions.create},
393246393246
it seems can be useful for optimizations in theory,
393247393247
in practice, it never happen, since the pattern match
393248-
never dig into it internally, so maybe {!Obj.set_tag}
393249-
is not necessary at all
393248+
never dig into it internally.
393249+
Alternative is to create a block `["xx"]` which relies on object identity
393250+
We try to avoid this, since inlining would break this, this would make reason
393251+
about the correctness of inlining more difficult
393250393252
*)
393251393253
let make exception_str : J.expression =
393252393254
E.runtime_call Js_runtime_modules.exceptions Literals.create [exception_str]
@@ -398996,7 +398998,7 @@ let classify (prog : string) : Js_raw_info.exp =
398996398998
match Parser_flow.parse_expression
398997398999
(Parser_env.init_env None prog) false with
398998399000
| (_, Function {
398999-
id = None;
399001+
id = _;
399000399002
params = (_, {params});
399001399003
async = false;
399002399004
generator = false;

0 commit comments

Comments
 (0)