Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007852OCamltypingpublic2018-09-21 18:462019-01-14 07:45
Assigned Totrefis 
PlatformOSOS Version
Product Version4.08.0+dev/beta1 
Target VersionFixed in Version 
Summary0007852: Spurious unused value warning with destructive substitution
DescriptionThis regression was introduced by [^]

I'll try to fix it without having to revert the GPR.
But if I fail, we can always revert it, it's not that important.
Steps To Reproduce$ cat test.mli
module M : sig
  type t
  val foo : t -> int
  val bar : t -> int

module N : sig
  type outer
  type t
  val foo : t -> outer
  val bar : t -> outer
end with type outer := int
$ ./ocamlc.opt -w +32 -c ./test.mli
File "./test.mli", line 10, characters 2-22:
Warning 32: unused value foo.
File "./test.mli", line 11, characters 2-22:
Warning 32: unused value bar.
$ $HOME/.opam/4.07.0/bin/ocamlc -w +32 -c ./test.mli
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
trefis (manager)
2018-09-21 18:47

Btw, this would also happen when destructively substituting a module.
trefis (manager)
2019-01-10 16:25

This was reverted in [^]

FTR, what was happening is basically this:

Usage of items in OCaml is tracked by their name (i.e. the string, not the ident) and a Location.
When first typing the "sig .. end" part of "sig .. end with ..." (that is done in Typemod), we enter the names and locations of foo and bar in some table in Env.
When we process the constraint (the "with ..." part) (also done in Typemod), we assign a new location to these items.

Once we're done with the typing (we're now in Compile_common.typecheck_intf), we call "ignore (Includemod.signatures info.env sg sg)". Which has the effect of marking every item in the signature as used (which makes sense for mlis).

The issue is that we're doing that by going over the signature, taking the name + location of every item, and then using that to look in the table in Env. But the location we have is the new one, not the initial one which was used to add the items to the table. So we never mark the items that were initially added.
And so we get the spurious warnings.
gasche (administrator)
2019-01-14 07:45

Thanks for the summary, I get it now. (Another motivation to have a proper "declaration path" notion instead of source locations.)

- Issue History
Date Modified Username Field Change
2018-09-21 18:46 trefis New Issue
2018-09-21 18:46 trefis Status new => assigned
2018-09-21 18:46 trefis Assigned To => trefis
2018-09-21 18:47 trefis Note Added: 0019378
2019-01-10 16:25 trefis Note Added: 0019545
2019-01-14 07:45 gasche Note Added: 0019547

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker