This week we merged several changes from Thomas Refis, to allow the
use of exception patterns under or-patterns, to write code such as
match foo x with
| None | exception Not_found -> ...
| Some -> ...
Unfortunately, I failed to properly assess the impact of this change,
and in particular to make sure that Luc Maranget had properly reviewed
this code -- any change to the pattern-matching machinery should be
reviewed by Luc.
The problem that I had not foreseen and that he would have immediately
realized is that, while adapting the pattern-matching *compiler* is
relatively easy (Thomas inserted a transformation at the right place
to separate exception patterns from the others and handle them
separately, using the staticraise construct used by the
pattern-matching compiler to avoid duplicating the
right-hand-side branch), adapting the pattern-matching warnings
machinery is both more subtle and easier to overlook (it may fail
silently and nobody notices, unlike wrong code production). This part
of the compiler is subtle and best understood by Luc, but he does not
have the time to do a proper review of those changes in the timeframe
for the 4.03 feature freeze (mid-December).
I believe the right move in this case, implemented in the present
commit, is to revert the change from trunk (this is not a feature that
we must *imperatively* have in 4.03), do a proper job of understanding
the changes, and integrate the change when we are confident it is
ready. I hope to do this in 2016, together with Luc Maranget and
Thomas Refis -- hopefully this would allow Thomas and I to be more
confident when changing the pattern-matching machinery in the future.
Revert "Merge pull request #343 from trefis/pr7083"
This reverts commit 22681b8d2a, reversing
changes made to a24e4edf0a.
Revert "Merge pull request #341 from trefis/or-exception"
This reverts commit f8f68bd329, reversing
changes made to 1534fe8082.
Revert "Merge pull request #305 from trefis/or-exception"
This reverts commit cfeda89396, reversing
changes made to 77cf36cf82.
This form used to produce Pstr_eval instead of Pstr_let. This would
probably come as a suprise for people matching on the Parsetree (e.g.
for a ppx). This special case is now removed.
To avoid a (probably harmless) regression in bytecode, the compilation
of "let _ = ..." bindings (including local ones) is optimized to remove
a useless introduction of a variable (which would occupy a stack slot
otherwise).
The source code printer (-dsource) now prints Pstr_eval as ";;expr",
which should always be ok. One could avoid ";;" at the beginning of
the structure, but since it is allowed, it is probably not worth adding
complexity here.
Adding [@unboxed] (resp [@untagged]) on a primitive argument means
that the argument must passed unboxed (resp untagged) to the external
function. Adding [@unboxed] (resp [@untagged]) on the result means
that the external function returns its result unboxed (resp untagged).
The unboxing (resp untagging) method is derived from the type.
Currently unboxing is suported for: float, int32, int64 and nativeint.
Untagging is supported for int.
This patch also increases the cm{i,o,a,x,xa} magic numbers as the type
Primitive.description is changed.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@16382 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
and unshared default clauses in the presence of many (>= 32) non-matched
constructors.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@15570 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Noticed that I had to bootstrap to test on ARM, so I commit a new bootstrap
compiler.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@14479 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
The whole "let's choose between two implementations of inline_lazy_force" smells. It should be possible to have one implementation that works well in bytecode and in native. TBD.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13761 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
(especially when we will add more powerful disambiguation strategies). The correct way to identify an item is through the pair (type,name), which can be deduced from the
label_description/constructor_description stored in the Typedtree.
git-svn-id: http://caml.inria.fr/svn/ocaml/trunk@13043 f963ae5c-01c2-4b8c-9fe0-0dff7051ff02
Damien Doligez
Leo White
Gabriel Scherer
Thomas Refis
maranget
alainfrisch
Nicolas Ojeda Bar
Jacques Garrigue
Damien Doligez
Jérémie Dimino
Xavier Leroy