Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Location.none is broken with the LLVM assembler in 4.03.0+beta2 #7226
Original bug ID: 7226
LLVM's assembler does not (apparently) accept negative column numbers, e.g.
.loc 2 1 -1
The result is that it is not possible to compile on systems that use Clang for assembly, with the -g flag, with a PPX that sometimes uses Location.none, because Location.none has a column number of -1:
/var/folders/wr/52wphbkn0zx5nvbx61v640nm0000gn/T/camlasmef96b3.s:2804:11: error: unexpected token in '.loc' directive
Steps to reproduce
.file 1 "none"
(* Changes location of all application expressions to Location.none. *)
let mapper _ =
let () =
let () =
PPX = ppx_loc_bug
.PHONY : build
.PHONY : clean
This was apparently introduced by #212
I propose to solve it by not emitting the column number if it is negative, i.e.
.loc 2 1
If this is reasonable, I can make a PR.
Comment author: @gasche
I see several ways to work around the problem:
(1) change the column-printing code of #212 to not emit the column when it is negative
Options (1) seems best to me. If you want to submit a PR, that would be very nice indeed. If you want it to be considered for inclusion into 4.03, it should be as non-invasive and "obviously non-regressing" as possible.
(We could also consider reverting #212 for 4.03 to be in the clear, but I'd rather not do that.)
Comment author: antron
It's a problem of OCaml.
If you are writing or maintaining a flawed PPX that emits Location.none, and you accidentally only use Location.none in constructs that don't cause emission of .loc directives, you won't notice that you have a problem.
And, if you use Location.none in constructs that do cause emission of .loc, but your OCaml is configured to assemble using the GNU toolchain, you still won't notice it.
If somebody else then tries to use your PPX on OCaml configured with the Clang toolchain, they will get a number of opaque error messages coming from the assembler.
The points are:
If it is genuinely important for OCaml that locations of expressions or other constructs are not Location.none, then I think the compiler should be modified to either check for Location.none, or to prevent or strongly discourage construction of ASTs with Location.none.
Comment author: @gasche
It's not even clear to me that using Location.none if ppx rewriters is a bad choice in the first place. For code that comes from user code, using user code locations is better, but there may be situations where it's reasonable to say that a particular code has "no location".
Let's get over this debate and fix the bug.
Comment author: @lefessan
Except that, when debugging a program, faulty ppx programs have the same impact on debuggers with "gas" (where there is a location, but it is incorrect) as with "clang" (if the location is removed). I think the best solution would be, at least, to issue a warning ("your ppx generates code with incorrect locations"), so that users can send bug reports upstream to ppx developers.
Comment author: @mmottl
I've created a small test case, reproducible with OPAM 4.03.0+flambda on Mac OS X.
type 'a t = 'a [@@deriving bin_io]
Compile it with:
ocamlfind ocamlopt -c -g -package ppx_bin_prot -o foo.cmx foo.ml
The important bit above is "-g". Without it the problem does not happen, neither does it without Flambda.