Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004775OCaml~DO NOT USE (was: OCaml general)public2009-04-23 23:542011-05-29 12:14
Assigned Togarrigue 
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.

=============== ~/ ====================
module type Poly = sig
  type 'a t = 'a constraint 'a = [> ]

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

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

> /janelibs/ocaml-3.11.0+jane3_64/bin/ocaml ~/
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 ~/
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
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...
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.
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
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-03-03 17:55 doligez Category -OCaml general => -(deprecated) general
2017-03-03 18:01 doligez Category -(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04 doligez Category ~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker