Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006446OCamlOCaml typingpublic2014-06-02 10:402014-06-02 18:47
Reporterfrisch 
Assigned Tofrisch 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version4.02.0+beta1Fixed in Version4.02.0+dev 
Summary0006446: "Unused stuff" warnings broken in presence of multiple values with the same name
DescriptionCommit 14896 introduces an intermediate coercion when a structure defines several values with the same name. This interacts badly with how the "unused stuff" warnings are implemented, because this coercion marks components as being used (they are "required" by the coercion).


Example:

module X : sig
  val y : int
end = struct
   let x = 1
   let y = 2
   let y = y
end
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0011618)
frisch (developer)
2014-06-02 10:48

A pseudo-fix could be to check that location are different between source and target declarations before marking the source as being used. E.g. for Includemod.value_descriptions:

let value_descriptions env cxt subst id vd1 vd2 =
  Cmt_format.record_value_dependency vd1 vd2;
  if vd1.val_loc <> vd2.val_loc then
    Env.mark_value_used (Ident.name id) vd1;
  ...


but this breaks the warnings for mli files (where we rely on the fact that the signature is matched against itself in compile.ml).
(0011619)
shinwell (developer)
2014-06-02 10:56

(Commit 14896 is the fix for PR 6435.)
(0011621)
frisch (developer)
2014-06-02 11:14

Fixed by commit 14936 on 4.02.
(0011622)
garrigue (manager)
2014-06-02 12:13

I'm afraid I don't understand the discussion here.
Introducing any coercion is should mark omitted components as being _unused_, not used.
Why is there any need to distinguish between implicit and explicit coercions?
Or is your tracking going down to the lambda code?
(0011624)
frisch (developer)
2014-06-02 17:20

The warnings are implemented by collecting references to values. When a signature S1 is matched against S2, this results in a value declaration X1 matched against the expected declaration X2, and the effect of it is to mark X1 as being used (it is required to make the inclusion check succeed). Consider for example:

module type S = sig val x : int end
module F(X : S) = struct ... end
module A = struct let x = 1 let y = 2 end
module B = F(A)


The signature inferred for A contains two value declarations (with location derived from the implementation). The inclusion check induced by the functor application checks that this signature is a subtype of S, and this results in marking "let x = 1" in A, but not "let y = 2" (which is not checked against any other declaration).

Basically, we assume that inclusion check corresponds to some kind of "static data flow".

Now, if we add an inclusion check between the signature inferred for A and itself, this will result in the declaration for "let y = 2" (val y: int) be matched against itself, and it will thus be marked as being used.

Does it make sense?
(0011625)
garrigue (manager)
2014-06-02 17:38
edited on: 2014-06-02 17:40

I see. This makes sense, but this is only an approximation.
If you have nested coercions, only the outermost one should do that. In practice, the signature of the compilation unit, or of a functor parameter (since we cannot know how it is used inside). But this may be harder to implement.

(0011626)
frisch (developer)
2014-06-02 17:51

The reasoning is that if a value is required to make an inclusion check succeed, it cannot be considered as unused. So even with nested coercions, this seems ok to me. But clearly, we don't do a full fledged data flow analysis, only a local approximation of it.

- Issue History
Date Modified Username Field Change
2014-06-02 10:40 frisch New Issue
2014-06-02 10:48 frisch Note Added: 0011618
2014-06-02 10:56 shinwell Note Added: 0011619
2014-06-02 10:56 shinwell Assigned To => garrigue
2014-06-02 10:56 shinwell Status new => acknowledged
2014-06-02 10:57 shinwell Status acknowledged => assigned
2014-06-02 11:03 frisch Assigned To garrigue => frisch
2014-06-02 11:03 frisch Note Added: 0011620
2014-06-02 11:14 frisch Note Added: 0011621
2014-06-02 11:17 frisch Note Deleted: 0011620
2014-06-02 11:20 shinwell Status assigned => resolved
2014-06-02 11:20 shinwell Fixed in Version => 4.02.0+dev
2014-06-02 11:20 shinwell Resolution open => fixed
2014-06-02 12:13 garrigue Note Added: 0011622
2014-06-02 17:20 frisch Note Added: 0011624
2014-06-02 17:24 shinwell Status resolved => assigned
2014-06-02 17:38 garrigue Note Added: 0011625
2014-06-02 17:40 garrigue Note Edited: 0011625 View Revisions
2014-06-02 17:51 frisch Note Added: 0011626
2014-06-02 18:47 frisch Status assigned => resolved


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker