0005167: camlp4r loops when printing package type

Notes
(0005693) ertai (developer) 2010-10-27 16:38	I don't know how to reproduce it with 3.12, all the following works well: camlp4r -printer r -str '(module M : S);' camlp4r -printer r -str '(module M : S.T with type t = u);' camlp4r -printer r -str 'type t = (module S);' Actually I just built the trunk (where you merged your branch) and this works fine: ./_build/camlp4/camlp4r.byte -printer r -str 'value f (module M : S) = ();' value f ((module M) : (module S)) = (); While it could be prettier by adding a special case for (module M : S).

(0005694) garrigue (manager) 2010-10-27 22:52	Using 3.12 syntax: tet-garrigue> ocaml dynlink.cma camlp4r.cma Objective Caml version 3.12.1+dev4 (2010-09-03) Camlp4 Parsing version 3.12.1+dev4 (2010-09-03) # module type S = sig type t; value x : t ; end; module type S = sig type t = <abstract>; value x : t; end # value f m = let module M = (value m : S) in (); value f : ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((

(0005697) ertai (developer) 2010-10-28 22:37	Oh, I got it the bug is not in the Camlp4 pretty-printer as defined in Camlp4/Printers/OCamlr?.ml but in the toplevel value printer in Caml4Top/Rprint.ml. This module has two main flaws: 1/ it redefines a printer even if we already have one, converting to the Camlp4 AST and then calling the pretty-printer would: * reuse code, to have only one pretty-printer in Camlp4 * be less brittle w.r.t. changes in this data type. 2/ In the mean time, having at least one exhaustive pattern-matching per syntactic class would help avoiding this problem again.

(0005798) xclerc (developer) 2011-02-10 16:06	fixed in branch "version/3.12"

Issue History
Date Modified	Username	Field	Change
2010-10-19 11:53	garrigue	New Issue
2010-10-19 11:53	garrigue	Status	new => assigned
2010-10-19 11:53	garrigue	Assigned To	=> ertai
2010-10-27 16:38	ertai	Note Added: 0005693
2010-10-27 22:52	garrigue	Note Added: 0005694
2010-10-28 22:37	ertai	Note Added: 0005697
2011-02-09 14:38	xclerc	Assigned To	ertai => xclerc
2011-02-10 16:06	xclerc	Note Added: 0005798
2011-02-10 16:06	xclerc	Status	assigned => resolved
2011-02-10 16:06	xclerc	Fixed in Version	=> 3.12.1+dev
2011-02-10 16:06	xclerc	Resolution	open => fixed
2012-09-25 20:06	xleroy	Status	resolved => closed

Relationships