Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006650OCamltypingpublic2014-11-08 04:342016-12-07 11:36
Reporterlpw25 
Assigned Togarrigue 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.03.0+dev / +beta1 
Summary0006650: Cty_constr not handled correctly by Subst
DescriptionCty_constr contains a path which is either to a class or a class type, but Subst treats them as type paths since it does not support substituting class or class type paths. This means that when Subst.signature renames all bound identifiers the class/class type paths are not properly updated.

Since Cty_constr is only consumed by the type printer, which only uses the name of the path, this doesn't cause any actual bugs. However, it is very annoying for tools which consume .cmi files.

I see a number of possible solutions for this:

1. Add support for substituting class and class type paths to Subst.

2. Cheat and add the class and class type idents as type substitutions in Subst.rename_bound_idents.

3. Don't rename classes and class types (and values and extension constructors) in rename_bound_idents. These idents have no semantic meaning, and are only used for printing, so there is really no need to rename them.

4. Put the corresponding object type path in Cty_constr (from cty_path) instead of the class or class type path. Then regular substitution of the object types will keep the paths up-to-date.

Personally, I think 3 would be the best solution.

Note that (if we don't do 4) it would also be a good idea to ensure that Cty_constr always contains a class type path rather than sometimes containing a class path.

Also note that the information in csig_inher is derived from Cty_constr, so it is also not correctly maintained by Subst.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0012498)
lpw25 (developer)
2014-11-08 04:49

Actually I can get this to cause a bug in the printer:

    # module type S = sig
        class type c = object method m : int end
        module M : sig
          class type d = c
        end
      end;;

    module type S =
      sig
        class type c = object method m : int end
        module M : sig class type d = c end
      end

    # module F (X : S) = X.M;;

    module F : functor (X : S) -> sig class type d = c end

See that `F` produces a module with a class type `d` that is equal to a non-existent class type `c`.
(0012499)
lpw25 (developer)
2014-11-08 04:53

The above bug would not be fixed by option 3 (although I think that is a good idea anyway because it simplifies the case of idents for values and type extensions).

So I think that one of 1 or 4 should be implemented as well, probably 4 since 1 would increase the size of all Subst.t's just to improve printing of class types.
(0012506)
garrigue (manager)
2014-11-10 10:49

Fixed in trunk at revision 15574.
Adopted solution (2): while this may be seen as cheating, the behavior is exactly the same for class/class types and types.

- Issue History
Date Modified Username Field Change
2014-11-08 04:34 lpw25 New Issue
2014-11-08 04:49 lpw25 Note Added: 0012498
2014-11-08 04:53 lpw25 Note Added: 0012499
2014-11-10 10:49 garrigue Note Added: 0012506
2014-11-10 10:49 garrigue Status new => resolved
2014-11-10 10:49 garrigue Fixed in Version => 4.03.0+dev / +beta1
2014-11-10 10:49 garrigue Resolution open => fixed
2014-11-10 10:49 garrigue Assigned To => garrigue
2016-12-07 11:36 xleroy Status resolved => closed
2017-02-23 16:45 doligez Category OCaml typing => typing


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker