Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007232OCaml~DO NOT USE (was: OCaml general)public2016-04-18 19:122016-04-19 14:42
Reporterantron 
Assigned Todoligez 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version4.03.0+dev / +beta1Fixed in Version4.03.0+dev / +beta1 
Summary0007232: Strange Pprintast output with ppx_deriving
DescriptionPrinting an AST produced by ppx_deriving.show with Pprintast results in different spacing than entering the same source code directly and printing that. I haven't fully diagnosed the issue due to a lack of time, but I suppose ppx_deriving.show is programmatically generating some AST construct that hasn't received as much attention as constructs generated by the OCaml parser for the literal code.

This complicates testing using textual diffs.
Steps To Reproduceopam install ocamlfind ppx_deriving ppx_tools.

foo.ml:

type a = Foo [@@deriving show]


Makefile:

PPX_DERIVING = `ocamlfind query ppx_deriving`
PPX = $(PPX_DERIVING)/ppx_deriving $(PPX_DERIVING)/ppx_deriving_show.cma

.PHONY : test
test :
    ocamlfind ppx_tools/rewriter -ppx '$(PPX)' foo.ml


This results in the output:

type a =
  | Foo [@@deriving show]
let rec (pp_a : Format.formatter -> a -> Ppx_deriving_runtime.unit) =
  ((let open! Ppx_deriving_runtime in
      fun fmt -> function | Foo -> Format.pp_print_string fmt "Foo.Foo")
  [@ocaml.warning "-A"])

and show_a : a -> Ppx_deriving_runtime.string=
  fun x -> Format.asprintf "%a" pp_a x


However, parsing and re-printing the let rec ... and ... definitions directly results in a space before the "=" character on the line with "and".
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0015791)
gasche (administrator)
2016-04-18 19:51

The spacing issue rings a bell, I wonder if it hasn't been already reported. Did you test using 4.02.3? Could you try to reproduce this on 4.03?
(0015793)
antron (reporter)
2016-04-18 19:54

It is reproducible on 4.03 beta2, the 4.03 branch where we fixed the Clang error I reported (of course), and 4.03 with GPR#539 (see https://github.com/ocaml/ocaml/pull/539#issuecomment-211482946 [^]).

IIRC, the output was much messier in 4.02.3. It looks like many parts of that mess have been cleaned up, so perhaps that's what is familiar.
(0015813)
doligez (administrator)
2016-04-19 14:42

Fixed in 4.03 (commit 747098ee734bc1f6cf309a830225af1eaf0460f4)
and trunk (commit 2605f7798e8d31045756d8ec1f15e531116511ae).

- Issue History
Date Modified Username Field Change
2016-04-18 19:12 antron New Issue
2016-04-18 19:51 gasche Note Added: 0015791
2016-04-18 19:54 antron Note Added: 0015793
2016-04-19 13:07 doligez Status new => confirmed
2016-04-19 13:07 doligez Target Version => 4.03.0+dev / +beta1
2016-04-19 14:33 doligez Assigned To => doligez
2016-04-19 14:33 doligez Status confirmed => assigned
2016-04-19 14:42 doligez Note Added: 0015813
2016-04-19 14:42 doligez Status assigned => closed
2016-04-19 14:42 doligez Resolution open => fixed
2016-04-19 14:42 doligez Fixed in Version => 4.03.0+dev / +beta1
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