Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007315OCamltypingpublic2016-08-03 11:492017-09-24 17:33
Reporterkosik 
Assigned Togasche 
PrioritylowSeveritytweakReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version4.03.0 
Target VersionFixed in Versionlater 
Summary0007315: location information in the typing error message could be made more precise
DescriptionAfter typing:

  type foo = (unit,unit,unit,unit,unit,unit) bar;;

Ocaml (correctly) reports that:

  Error: Unbound type constructor bar

What I do not understand is why the location information is so vague.
Currently Ocaml pin-points the problem to:

  "(unit,unit,unit,unit,unit,unit) bar"

Why doesn't it provide a more precise location, i.e. where

  "bar"

identifier actually occurs?
Steps To Reproduceecho 'type foo = (unit,unit,unit,unit,unit,unit) bar;;' | ocaml
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0016180)
gasche (developer)
2016-08-03 12:06
edited on: 2016-08-03 12:06

This particular imprecision is fixed by the following one-line change:

diff --git a/typing/typetexp.ml b/typing/typetexp.ml
index e0d06dd..ccc760a 100644
--- a/typing/typetexp.ml
+++ b/typing/typetexp.ml
@@ -340,7 +340,7 @@ let rec transl_type env policy styp =
     let ty = newty (Ttuple (List.map (fun ctyp -> ctyp.ctyp_type) ctys)) in
     ctyp (Ttyp_tuple ctys) ty
   | Ptyp_constr(lid, stl) ->
- let (path, decl) = find_type env styp.ptyp_loc lid.txt in
+ let (path, decl) = find_type env lid.loc lid.txt in
       let stl =
         match stl with
         | [ {ptyp_desc=Ptyp_any} as t ] when decl.type_arity > 1 ->


What are other error messages whose location should be similarly refined?

(0016181)
kosik (reporter)
2016-08-03 12:44

I do not know about other scenarios in which Ocaml compiler produces unnecessarily vague location information. I can promise to report them once I spot them.

However, if Merlin has a separate typechecking engine from Ocaml compiler, it may also make sense to fix it in a similar way, because it behaves consistently (imprecisely) with the Ocaml compiler.
(0016182)
gasche (developer)
2016-08-03 13:07

Proposed fix in
  https://github.com/ocaml/ocaml/pull/736 [^]
(0016184)
gasche (developer)
2016-08-04 11:06

Fixed in trunk. Thanks for the enhancement proposal!

- Issue History
Date Modified Username Field Change
2016-08-03 11:49 kosik New Issue
2016-08-03 12:06 gasche Note Added: 0016180
2016-08-03 12:06 gasche Assigned To => gasche
2016-08-03 12:06 gasche Status new => confirmed
2016-08-03 12:06 gasche Note Edited: 0016180 View Revisions
2016-08-03 12:44 kosik Note Added: 0016181
2016-08-03 13:07 gasche Note Added: 0016182
2016-08-04 11:06 gasche Note Added: 0016184
2016-08-04 11:06 gasche Status confirmed => resolved
2016-08-04 11:06 gasche Fixed in Version => later
2016-08-04 11:06 gasche Resolution open => fixed
2017-02-23 16:45 doligez Category OCaml typing => typing
2017-09-24 17:33 xleroy Status resolved => closed


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker