Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005369OCamlOCaml generalpublic2011-10-04 09:542011-12-23 17:58
ReporterJulien Signoles 
Assigned Todoligez 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.12.1 
Target VersionFixed in Version3.13.0+dev 
Summary0005369: Wrong error location with records
DescriptionConsider the following buggy program:

=== a.ml ===
let a = { A.a = 0 }
============

$ ocamlc -c a.ml
File "a.ml", line 3, characters 16-17:
Error: Unbound module A

The error is located on 0. It should be located on A (or A.a).
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0006149)
doligez (administrator)
2011-10-05 18:54

This is more or less done on purpose. The parser doesn't save the location information for the label itself, so the only alternative would be to locate the error on the whole record expression (characters 8-17 in your example). It would be more accurate but less precise.

I can make the change if you have a compelling argument.
(0006154)
Julien Signoles (reporter)
2011-10-06 10:52

When (among others refactoring changes) you are replacing A by X.A by compiling/showing-next-error/pasting 'X.' in your favorite text editor, it is a waste of time if the error is wrongly located.

IMHO Locating the error on the whole record expression (your proposal) instead of on the innermost expression does not fully solve this issue, but perhaps it helps a little bit since you would go to the right location faster.

Also, for tools who try to use OCaml error messages to automatically fix standard mistakes, your proposal could be better than the current issue. But I'm not an expert of such tools: ask to the OCamlpro's leader ;-).

Last but not least, in static analysis tools, overapproximations are always better than more-precise-but-incorrect results...
(0006200)
Julien Signoles (reporter)
2011-11-10 10:51

I just fall back on this issue. I confirm that the current behavior is very annoying since you search the error somewhere in the located area (which may be a complicated expression) and you don't understand why you don't find the offending label.
(0006523)
doligez (administrator)
2011-12-23 17:58
edited on: 2011-12-23 18:06

Fixed in the 3.12 branch (revision 11949). The error location is now on the whole record.

Note: in the trunk, this problem has disappeared, as a result of an (apparently) unrelated modification of the typing algorithm. The location is also on the whole record.


- Issue History
Date Modified Username Field Change
2011-10-04 09:54 Julien Signoles New Issue
2011-10-05 18:38 doligez Status new => assigned
2011-10-05 18:38 doligez Assigned To => doligez
2011-10-05 18:54 doligez Note Added: 0006149
2011-10-05 18:54 doligez Status assigned => feedback
2011-10-06 10:52 Julien Signoles Note Added: 0006154
2011-11-10 10:51 Julien Signoles Note Added: 0006200
2011-12-23 17:13 doligez Status feedback => assigned
2011-12-23 17:58 doligez Note Added: 0006523
2011-12-23 17:58 doligez Status assigned => closed
2011-12-23 17:58 doligez Resolution open => fixed
2011-12-23 17:58 doligez Fixed in Version => 3.13.0+dev
2011-12-23 18:06 doligez Note Edited: 0006523 View Revisions


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker