Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004775OCamlOCaml generalpublic2009-04-23 23:542011-05-29 12:14
Reportercfalls 
Assigned Togarrigue 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.11.0 
Target VersionFixed in Version3.11.1+dev 
Summary0004775: compiler crashes on crazy types
DescriptionThe following program crashes several versions of the compiler. I discovered this bug when fiddling around with type constraints -- I doubt it would be triggered by any program that was written to do something useful.

=============== ~/bug2.ml ====================
module type Poly = sig
  type 'a t = 'a constraint 'a = [> ]
end

module Combine (A : Poly) (B : Poly) = struct
  type ('a, 'b) t = 'a A.t constraint 'a = 'b B.t
end

module C = Combine
  (struct type 'a t = 'a constraint 'a = [> ] end)
  (struct type 'a t = 'a constraint 'a = [> ] end)
=============== ~/bug2.ml ====================

> /janelibs/ocaml-3.11.0+jane3_64/bin/ocaml ~/bug2.ml
Fatal error: exception Ctype.Unify(_, _)
(Program not linked with -g, cannot print stack backtrace)

> /janelibs/ocaml-3.11.0+jane3_64/bin/ocaml -version
The Objective Caml toplevel, version 3.11.0+jane3

> /usr/local/home/godi310/godi/bin/ocaml ~/bug2.ml
Fatal error: exception Ctype.Unify(_, _)
(Program not linked with -g, cannot print stack backtrace)

> /usr/local/home/godi310/godi/bin/ocaml -version
The Objective Caml toplevel, version 3.10.1+dev0 (2007-05-21)
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0004924)
garrigue (manager)
2009-04-27 10:41

Thanks for this interesting report.
Indeed your crazy types are not crazy at all, and
I believe the code you describe should be accepted.
But the cause of the bug, in Ctype.nondep_type_rec, is the use
of unification in expand_abbrev combined with a special representation
with Tsubst nodes, which was introduced about 10 years ago, so I believe
that no version since 2.99 can compile it.
It would be interesting to see whether ocaml 2.04 can compile it, as
I have my doubt about the correctness of the previous code too.

I'm still looking for a workaround...
(0004956)
garrigue (manager)
2009-05-19 07:44

Actually the first explanation was wrong. The real trouble here is
the use of a curried functor. If you uncurry it (use two submodules as argument),
then this program is accepted. A real fix would be either in Mtype or Typemod.

As a temporary fix, I catch Unify in Ctype.nondep_type_rec.
Curiously, this does not results in a failure, but just in making t abstract
in the result.
(0004958)
garrigue (manager)
2009-05-19 10:25

A better solution is now commited in head branch (3.12+dev),
solving both the problem with nondep_type (do not modify types during copying)
and Mtype.nondep_mty (extend environment when eliminating in functors).
Your example is now typable with this version.

- Issue History
Date Modified Username Field Change
2009-04-23 23:54 cfalls New Issue
2009-04-27 10:41 garrigue Note Added: 0004924
2009-04-27 10:41 garrigue Assigned To => garrigue
2009-04-27 10:41 garrigue Status new => confirmed
2009-05-19 07:44 garrigue Note Added: 0004956
2009-05-19 07:44 garrigue Status confirmed => resolved
2009-05-19 07:44 garrigue Fixed in Version => 3.11.1+dev
2009-05-19 07:44 garrigue Resolution open => fixed
2009-05-19 10:25 garrigue Note Added: 0004958
2011-05-29 12:14 xleroy Status resolved => closed


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker