Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange Pprintast output with ppx_deriving #7232

Closed
vicuna opened this Issue Apr 18, 2016 · 3 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link
Collaborator

vicuna commented Apr 18, 2016

Original bug ID: 7232
Reporter: antron
Assigned to: @damiendoligez
Status: closed (set by @damiendoligez on 2016-04-19T12:42:37Z)
Resolution: fixed
Priority: normal
Severity: minor
Target version: 4.03.0+dev / +beta1
Fixed in version: 4.03.0+dev / +beta1
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @hcarty

Bug description

Printing 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 reproduce

opam 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".

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 18, 2016

Comment author: @gasche

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?

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 18, 2016

Comment author: antron

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 #539 (see #539 (comment)).

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 19, 2016

Comment author: @damiendoligez

Fixed in 4.03 (commit 747098e)
and trunk (commit 2605f77).

@vicuna vicuna closed this Apr 19, 2016

@vicuna vicuna added this to the 4.03.0 milestone Mar 14, 2019

@vicuna vicuna added the bug label Mar 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.