Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006795OCaml~DO NOT USE (was: OCaml general)public2015-02-27 08:452017-02-16 15:18
Reporterwhitequark 
Assigned Todim 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version4.03.0+dev / +beta1Fixed in Version4.03.0+dev / +beta1 
Summary0006795: ocamldep should error out if a rewriter returns an error
DescriptionCurrently, if a rewriter returns an error, ocamldep blindly processes the [%%ocaml.error] node instead, and returns no dependency information at all, which causes the rest of compilation to fail in unexpected and confusing ways (no module found) if it does in fact depend on dependencies being present.

This happens with my package ppx_import.
TagsNo tags attached.
Attached Files

- Relationships
has duplicate 0006996closeddim ocamldep should detect ppx rewriter errors reported via [%%ocaml.error] 

-  Notes
(0013353)
gasche (administrator)
2015-02-27 15:09

I'm not convinced that being stricter at what we accept won't break existing tooling in subtle way. The safest choice is probably to do exactly as for camlp4 here: what happens if ocamldep is called on a file whose preprocessor rejects?
(0013354)
whitequark (developer)
2015-02-27 15:11

No, that wouldn't work. camlp4 reports the error itself and exits; ppx has to always return a valid AST and rely on the compiler reporting the error.
(0013358)
gasche (administrator)
2015-02-27 16:51

I agree on principle on the idea of adding code to ocamldep to detect the specific error-return convention of -ppx. It's just that I don't know how robust or how fragile ocamldep is when dealing with camlp4 preprocessing errors, and I suggest to make it exactly as robust (and fragile) with ppx errors (recognized as such).
(0013359)
whitequark (developer)
2015-02-27 16:53

I believe adding such error handling code to the -ppx branch would do what you want.
(0015167)
dim (developer)
2015-12-17 11:16

When camlp4 fails, ocamldep fails as well but still prints deps:

# cat test.ml
let a = Foo.a
let x = -
# cat foo.ml
let a = 42
# ocamldep -pp camlp4o test.ml
File "test.ml", line 1, characters 8-9:
Parse error: [expr] expected after "-" (in [expr])
File "test.ml", line 1:
Error: Error while running external preprocessor
Command line: camlp4o 'test.ml' > /tmp/ocamlpp5879b9

test.cmo :
test.cmx :
# echo $?
2
# ocamldep -allow-approx -pp camlp4o test.ml
File "test.ml", line 2, characters 8-9:
Parse error: [expr] expected after "-" (in [expr])
File "test.ml", line 1:
Error: Error while running external preprocessor
Command line: camlp4o 'test.ml' > /tmp/ocamlpp40ff36

test.cmo : foo.cmo
test.cmx : foo.cmx
# echo $?
0

I'm writing a patch to do the same with -ppx errors.
(0015168)
dim (developer)
2015-12-17 11:26

One thing I'm wondering is whether we should fail for all uninterpreted extensions. If an extension isn't interpreted, then the result of ocamldep might be completely wrong anyway.
(0015169)
dim (developer)
2015-12-17 11:44

Fixed in commit b95a642.

- Issue History
Date Modified Username Field Change
2015-02-27 08:45 whitequark New Issue
2015-02-27 15:09 gasche Note Added: 0013353
2015-02-27 15:11 whitequark Note Added: 0013354
2015-02-27 16:51 gasche Note Added: 0013358
2015-02-27 16:53 whitequark Note Added: 0013359
2015-03-17 23:32 doligez Status new => acknowledged
2015-03-17 23:32 doligez Target Version => 4.02.3+dev
2015-07-10 16:52 doligez Target Version 4.02.3+dev => 4.03.0+dev / +beta1
2015-12-17 10:56 dim Assigned To => dim
2015-12-17 10:56 dim Status acknowledged => assigned
2015-12-17 10:57 dim Relationship added has duplicate 0006996
2015-12-17 11:16 dim Note Added: 0015167
2015-12-17 11:26 dim Note Added: 0015168
2015-12-17 11:44 dim Note Added: 0015169
2015-12-17 11:44 dim Status assigned => resolved
2015-12-17 11:44 dim Fixed in Version => 4.03.0+dev / +beta1
2015-12-17 11:44 dim Resolution open => fixed
2017-02-16 15:18 xleroy Status resolved => closed
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