Instead of the erasure scheme that was used up to now, where we
considered that the type was always principal.
Note: the erasure still happens when polymorphic variants appear in the
patterns, and the type of the scrutinee contains a Reither.
Add hint when a module is used instead of a module type or when a
module type is used instead of a module or when a class type is
used instead of a class.
This PR fixes an old bug in the interaction between [merge_constraint]
and [Typedecl.transl_with_constraint], where
variance (and now separability) are recomputed in an invalid type
environment. See #9624 and the new tests.
In -no-flat-float-array mode, instead of always returning
`best_msig` (the most permissive signature), we first compute the
flat-float-array separability signature -- falling back to `best_msig`
if it fails.
This discipline is conservative: it never rejects -no-flat-float-array
programs. At the same time it guarantees that, for any program that is
also accepted in -flat-float-array mode, the same separability will be
inferred in the two modes. In particular, the same .cmi files and
digests will be produced.
Before we introduced this hack, the production of different .cmi files
would break the build system of the compiler itself, when trying to
build a -no-flat-float-array system from a bootstrap compiler itself
using -flat-float-array. See #9291.
We produce exhaustivity counter-example in the order of the
specialized submatrices. Having submatrices in source order gives the
nice behavior that the clause that would naturally been inserted first
in the source is given first as a counter-example.
Consider for example:
function
| true, true -> true
| false, false -> false
The two counter-examples are (true, false) and (false, true).
Before this patch, (false, true) would be shown first.
After this patch, (true, false) is shown first.
This corresponds to the following natural completion order:
function
| true, true -> true
| true, false -> ?
| false, false -> false
| false, true -> ?
On the other hand, the ordering of the default submatrix, with respect
to the specialized submatrices, is not preserved -- it is always
ordered last.
One could intuitively expect the default submatrix to appear in the
position of the first omega row in the source. We tried this, and
it is not a good idea:
- the change is much more invasive as the interface of
`build_specialized_submatrices` has to change
- the behavior of the result is in fact unpleasant; it is not
intuitive to order counter-examples in this way.
For example, consider:
function
| _, None -> false
| true, Some true -> false
The two exhaustivity counter-examples are (true, Some false)
and (false, Some _). The second comes from the default submatrix:
morally it is (_, Some _), with "some other constructor missing from
the column" instead of the first _. There is no reason to suppose that
the user would want to place this (_, Some _) or (false, Some _)
counter-example first in the completed code; indeed, this intuition
would suggest writing an exhaustive covering of patterns of the
form (_, foo), inserted after the first clause, but then the other
clauses below become unnecessary!
When an omega patterns appears high in the column like this, it is
usually because there is a very specific matching condition to the
rest of its row, that justifies some shortcutting behavior. The
program is typically *not* completed by adding more specific matching
conditions.
This solves exponential-blowup issue with the strict traversal and/or
strict witness computation in cases where an exponential number of
counter-examples is generated. This fixes Stack Overflow and
exponential-time issues on examples using or-patterns heavily,
including one that naturally found its way in real-world user
code (see the following testsuite commit).
We now systematically keep only one counter-example, instead of
letting the type-checker decide whether to discard
counter-examples (in Backtrack_or mode) or to preserve
them (in Refine_or mode).
Note: in the exhaustivity warning, there are sub-messages printed to
indicate that:
- the exhaustivity counter-example is related to an extensible type, or
- that a when-guarded clause does match the counter-example
In both cases the warning is there to explain the counter-example(s)
shown (not a property of all counter-examples); keeping at most one
valid counter-example means that they will be printed less often, but
it is the correct/intended behavior in that case.
The aim is to also move the Simple/Half_simple/General stuff from
matching, but we need to split in those modules the part that are
purely structural (they go in Patterns) and the parts that are
actually compilation logic (Half_simple.of_clause), those stay in
Matching.
We don't want to record the state of the file system at the start
of the compilation in the compiled files.
Consequently, we only add persistent modules to the env summary
if they have an observable action on the initial environment.
This is only the case if they shadow a non-persistent module of the
initially opened library (which can only be Stdlib currently).
This commit reverts c1a7ace (originally c545e04), which was a
temporary fix that is no longer needed because it was superseded by
#6608.
The temporary fix caused `{expr with lbl1 = e1; ... }` to not evaluate
`expr` if all labels of its type are overriden. As reported in #7696
this is not desirable. Reverting the temporary fix causes `expr` to
be evaluated always.
As a consequence, a corner case of value "let rec" is no longer accepted.
The corresponding test was updated.
Closes: #7696
This commit exposes all extension constructors when looking up for
a construction with a given type in the environment.
This makes constructor disambiguation work for extension constructors.
Going one step further, when the name of an extension constructors
is misspelled, we cannot rely on the type to find all possible
names. However, since we are in an error path, we have some
path at hand.
Thus, this commit alters the "lookup_from_type" function in the
Constructor module to make it scan the whole environment for
extension constructors with the right type.
This commit should not change anything for labels and standard constructors.
* Move driver code from Cmt2annot to Read_cmt
* Move cmt2annot.ml into typing/
* make depend
* Use standard error handling
* Move specific logic to read_cmt
* Do not pass full cmt record as argument
* Better locations
* Emit .annot files produced from cmt data
* Remove direct calls to Stypes
* Deprecate -annot
* Changes
* make depend
* Adapt doc
* make -C tools depend
`build_subtype` is invoked only through `enlarge_type` when typechecking Pexp_coerce.
The type passed to `build_subtype` can only have `Cok` arrows because:
- the base type is the direct result of `Typetexp.transl_simple_type_delayed` which only introduces `Cok` arrows
- the other source of arrows could be the result of unification; however at this point the type variables are fresh, they have not been unified with any existing types.
Adding this assertion ensures that this property won't be broken by accident.