1. In this `with' constraint, the new definition of Time [2 distinct symptoms]

   - Core__Core_time_float.add
   - Core__Core_time_float.epoch
   - Core__Core_time_float.Span.of_sec
         lib/core_kernel/src/timing_wheel_ns.ml, line 135, characters 25-68
       This is a bug:
         The dependency
           core_kernel.Timing_wheel_ns_intf%Alarm_precision.Time[...] -> foo
         should generate a dependency on
           core_kernel.Timing_wheel_ns.Time_ns[...] -> foo
         which would in turn generate the dependency
           core_kernel.Time_ns_alternate_sexp[...] -> foo

   - Core__Time_ns.epoch
   - Core__Time_ns.Span.of_sec
   - Core__Time_ns.Span.scale
   - Core_kernel__Time_ns_alternate_sexp.epoch
   - Core_kernel__Time_ns_alternate_sexp.sub
   - Core_kernel__Time_ns.add
   - Core_kernel__Time_ns.Span.of_sec
         lib/core/src/timing_wheel_float.mli, line 23, characters 8-77
       This is a bug:
         The dependency
           core_kernel.Timing_wheel_ns_intf%Timing_wheel.Time[...] -> foo
         should generate a dependency on
           core.Core_time_float[...]

--------------------------------------------------------------------------------
2. Signature mismatch: [...] is expected but not provided [21 distinct symptoms]

   - Base__Array.[fold,iter,length,sum,to_list]
   - Base__List.[exists,find_map,fold,for_all,is_empty,iter,length]
   - Base__Option.[fold,iter,to_list]
   - Base__Set.to_list
   - Base__Set.Using_comparator.to_list
   - Base__Set.Using_comparator.Tree.to_list
   - Base__String.[exists,iter]
   - Core_kernel__Array.
       [exists,find,fold,for_all,iter,length,max_elt,min_elt,to_list]
   - Core_kernel__Doubly_linked.
       [exists,find,find_map,fold,for_all,iter,length,to_array,to_list]
   - Core_kernel__Fqueue.to_list
   - Core_kernel__Heap.Removable.[iter,length,to_list]
   - Core_kernel__Linked_queue.[is_empty,length]
   - Core_kernel__List.[
         exists,find,find_map,fold,for_all,is_empty,iter,length,max_elt,min_elt,
         sum,to_array
       ]
   - Core_kernel__Option.[fold,iter]
   - Core_kernel__Queue.[is_empy,to_list]
   - Core_kernel__Sequence.[fold_until,iter,to_list]
   - Core_kernel__Set.[is_empty,length,to_list]
   - Core_kernel__String.[exists,for_all,to_list]
         lib/base/src/container.ml, line 151, characters 69-70
       This is a bug:
           lib/base/src/container.ml:141--159
         contains a number of functor applications which exist to perform 
         compile-time checks for consistency between different interfaces. In 
         this case, the value is renamed in an interface which is the declared 
         type of a parameter to a functor (e.g. base.Container.Check_S1), in the
         body of which the parameter is used as the argument to an application
         of the base.Container.Check functor. The bug is that a dependency is
         not generated on renaming the value in the parameter of this functor.
         E.g.
           base.Container_intf%S1:fold -> foo
         should generate a dependency on
           base.Container#Check[3]:fold -> foo
         which, in turn, should generate a dependency on
           base.Container_intf%Generic:fold -> foo

   - Base__Array.of_list
   - Core_kernel__array.of_list
         lib/core_kernel/src/container_unit_tests.ml, line 156, characters 18-23
       This is a bug:
         The dependency
           core_kernel.Array:of_list -> foo
         should generate a dependency on
           core_kernel.Container_unit_tests#Test_S1[1]:of_list -> foo

   - Base__Map.[add,find,fold,mem,remove,to_alist]
   - Base__Map.Using_comparator.
       [add,of_alist_exn,of_tree,remove,to_alist,to_sequence,to_tree]
   - Base__Map.Using_comparator.Tree.[
           add,add_multi,append,change,closest_key,compare_direct,count,counti,
           data,equal,exists,existsi,filter,filter_keys,filter_map,filter_mapi,
           filteri,find,find_exn,fold,fold_range_inclusive,fold_right,for_all,
           for_alli,invariants,is_empty,iter,iter_keys,iteri,keys,length,map,
           mapi,max_elt,max_elt_exn,mem,merge,min_elt,min_elt_exn,nth,nth_exn,
           of_alist,of_alist_exn,of_alist_fold,of_alist_multi,of_alist_or_error,
           of_alist_reduce,of_increasing_iterator_unchecked,of_iteri,
           of_sorted_array,of_sorted_array_unchecked,partition_map,
           partition_mapi,partition_tf,partitioni_tf,range_to_alist,rank,remove,
           remove_multi,singleton,split,subrange,symmetric_diff,to_alist,
           to_sequence,update,validate
         ]
   - Core_kernel__Int.Map.[empty,equal,of_alist_exn,singleton]
   - Core_kernel__Map.[
           add,data,empty,find,find_exn,fold,is_empty,iter,iter_keys,iteri,keys,
           length,map,mapi,mem,merge,of_sorted_array_unchecked,remove,to_alist,
           update
         ]
   - Core_kernel__Map.Poly.empty
   - Core_kernel__String.Map.[data,empty,keys,of_alist]
   - Core_kernel__Type_equal.Id.Uid.Map.empty
       This is a bug:
           lib/base/src/map_intf.ml:984--1022
           lib/base/src/map_intf.ml:1167--1197
         contains a number of functor applications which exist to perform 
         compile-time checks for consistency between different interfaces. In 
         this case, the value is renamed in an interface which is the declared 
         type of a parameter to a functor (e.g. base.Map_intf.Check_accessors1),
         in the body of which the parameter is used as the argument to an 
         application of the e.g. base.Map_intf.Check_accessors functor. The bug
         is that a dependency is not generated on renaming the value in the 
         parameter of this functor. E.g.
           base.Map_intf%Accessors1:add -> foo
         should generate a dependency on
           base.Map_intf#Check_accessors[5]:add -> foo
         which, in turn, should generate a dependency on
           base.Map_intf%Accessors_generic:add -> foo

   - Base__Set.[add,elements,mem,remove,union]
   - Base__Set.Using_comparator.[add,of_list,of_tree,remove,to_sequence,to_tree]
   - Base__Set.Using_comparator.Tree.of_list
   - Core_kernel__Char.Set.of_list
   - Core_kernel__Float.Set.[of_sorted_array_unchecked,union_list]
   - Core_kernel__Int.Set.[empty,filter,inter,max_elt,mem,of_list,singleton]
   - Core_kernel__Set.[add,diff,empty,equal,filter,inter,mem,union]
   - Core_kernel__Set.Poly.stable_dedup_list
   - Core_kernel__String.Set.of_list
         lib/base/src/set_intf.ml", line 442, characters 5-6
       This is a bug:
           lib/base/src/set_intf.ml:426--469
           lib/base/src/set_intf.ml:603--646
         contains a number of functor applications which exist to perform 
         compile-time checks for consistency between different interfaces. In 
         this case, the value is renamed in an interface which is the declared 
         type of a parameter to a functor (e.g. base.Set_intf.Check_accessors0),
         in the body of which the parameter is used as the argument to an 
         application of the e.g. base.Set_intf.Check_accessors functor. The bug
         is that a dependency is not generated on renaming the value in the 
         parameter of this functor. E.g.
           base.Set_intf%Accessors0:add -> foo
         should generate a dependency on
           base.Set_intf#Check_accessors[6]:add -> foo
         which, in turn, should generate a dependency on
           base.Set_intf%Accessors_generic:add -> foo

   - Base__Char.[compare,equal]
   - Base__Float.[compare,equal]
   - Base__Int.[equal,max,min]
   - Base__Nativeint.compare
   - Core_kernel__Char.[compare,equal]
   - Core_kernel__Float.[compare,max,min]
   - Core_kernel__Int.[equal,min,max]
   - Core_kernel__Int.Replace_polymorphic_compare.equal
   - Core_kernel__Nativeint.compare
   - Core_kernel__Time_float.compare
   - Core_kernel__Type_equal.Id.Uid.equal
         lib/base/src/comparable.ml", line 123, characters 83-1307
       This is a bug:
         The dependency
           base.Comparable_intf%S[...] -> foo
         should generate a dependency on
           base#Make_using_comparator[...] -> foo
         which, in turn, should generate dependencies on
           base#Make_using_comparator.Replace_polymorphic_compare.Without_squelch[...] -> foo
           base#Make_using_comparator.Replace_polymorphic_compare[...] -> foo

   - Base__Error.compare
         lib/base/src/comparable.ml, line 109, characters 29-56
       This is a bug:
         The dependency
           base.Comparable#Poly.Replace_polymorphic_compare:compare -> foo
         should generate a dependency on
           base.Comparator#Make[1]:compare -> foo
         from the functor application on the line referenced above.

   - Base__Hash_set.create
         lib/base/src/hash_set.ml, line 165, characters 6-366
       This is a bug:
         The dependency
           base.Hash_set_intf%Creators:create -> foo
         should generate the dependency
           base.Hash_set#Creators:create -> foo

   - Base__Hashtbl.create
   - Base__Hashtbl.Using_hashable.create
   - Core_kernel__Hashtbl.create
         lib/base/src/hashtbl.ml, line 753, characters 6-1497
       This is a bug:
         The dependency
           base.Hashtbl_intf%Creators:create -> foo
         should generate the dependency
           base.Hashtbl#Creators:create -> foo

   - Base__Import.of_sexp_error_exn
         lib/core_kernel/src/import.ml, line 45, characters 3-15
       This is a bug:
         The corresponding value in the module type annotation of the module
         alias is not renamed - is the module type annotation not traversed?

   - Base__Int.of_float
   - Base__Int.to_float
   - Core_kernel__Int.of_float
         lib/base/src/int64.ml, line 179, characters 25-231
         lib/base/src/int32.ml, line 180, characters 25-231
         lib/base/src/nativeint.ml, line 176, characters 25-231
         lib/base/src/int.ml, line 201, characters 28-229
       This is a bug:
         The dependency
           base.Floatable%S[...] -> foo
         should generate the dependency
           base.Int_math.T[...] -> foo
         which, in turn, should generate the dependency
           base.Int_math#Make[1][...] -> foo

   - Base__Result.return
   - Core_kernel__Option.return
   - Core_kernel__Quickcheck.Generator.return
         lib/base/src/applicative.ml, line 39, characters 9-99
       This is a bug:
         The dependency
           base.Applicative#Make2:return -> foo
         should generate a dependency on
           base.Applicative#Make[1]:return -> foo
         However this is a case in which an anonymous (functor argument) module
         needs to be analysed.

   - Base__String.blit
   - Core__Bigstring.blit
   - Core__Bigstring.From_string.blit
   - Core__Bigstring.To_string.blit
   - Core__Iobuf.Blit.[subo,unsafe_blit]
   - Core_kernel__Bigstring.From_string.blit
   - Core_kernel__Bigstring.subo
   - Core_kernel__Obj_array.blit
   - Core_kernel__Option_array.blit
   - Core_kernel__String.blit
         lib/core_kernel/src/array.ml, line 269, characters 6-502
       This is a bug:
         Essentially, the cause is that the dependency
           base.Blit#Make:blit -> foo
         doesn't generate the dependency
           base_for_tests.Test_blit#Make_and_test.B.blit -> foo
         which, in turn, should generate the dependency
           base_for_tests.Test_blit#Make_and_test.blit -> foo
         which, in turn, should generate the dependency
           core_kernel.Array.T.Int:blit -> foo
         which, in turn, should generate the dependency
           core_kernel.Blit%S_permissions:blit -> foo
         Perhaps the first step in this chain is not happening because the
         module base_for_tests.Test_blit#Make_and_test.B is an alias for a
         functor application?

   - Base__String.sub
   - Core__Iobuf.Blit.[blito,sub]
   - Core_kernel__Bigstring.blito
   - Core_kernel__Bigstring.From_string.blito
   - Core_kernel__Bigstring.To_string.blito
   - Core_kernel__Obj_array.sub
   - Core_kernel__String.sub
         lib/core_kernel/base_for_tests/src/test_blit.ml, line 156, characters 5-11
       This is a bug:
         The value is renamed in an interface base.Blit_intf%S that is declared
         to be the type of the functor parameter 
           base_for_tests.Test_blit#Test1[2]
         and this parameter is then used as an argument to the functor
           base_for_tests.Test_blit#Test_gen
         The following dependency fails to be generated
           base_for_tests.Test_blit#Test_gen[2]:sub -> foo

   - Core__Core_time_float.Zone.local
         lib/core/src/interval.ml, line 842, characters 27-36
       This is a bug:
         The dependency
           core.Import_time.Time.Zone:local -> foo
         should generate the dependency
           core.Interval#Make_time[1].Zone:local -> foo
         from the functor application on the line referenced above.

   - Core__Core_unix.Inet_addr.of_string
         lib/core/src/core_unix.ml, line 2048, characters 40-42
       This is a bug:
         The dependency
           core.Core_unix.Inet_addr0.Stable.V1.T0:of_string -> foo
         should generate the dependency
           core_kernal.Sexpable#Of_stringable[1]:of_string -> foo
         from the functor application on the line referenced above.

   - Core__Import.raise
   - Core_kernel__Std_internal.raise
         lib/core_kernel/src/core_pervasives.ml, line 28, characters 10-25
       This is a bug:
         The dependency
           core_kernel.Core_pervasives.Core_pervasives:raise -> foo
         should generate the dependency
           core_kernel.Core_pervasives.Modified_INRIA_Pervasives:raise -> foo
         because of the module type annotation in the module include on the line
         referenced above. However, the module type annotation uses module type
         extraction:
           include ((Core_pervasives : module type of Modified_INRIA_pervasives) : sig end)

   - Core__Time_ns.Span.zero
   - Core_kernel__Time_ns_alternate_sexp.Span.zero
         lib/core_kernel/src/time_ns.ml, line 263, characters 40-156
       This is a bug:
         the dependency
           core.Time_ns.Span.T:zero -> foo
         should generate the dependency
           core_kernel.Comparable#Validate_with_Zero[1]:zero -> foo
         due to the functor application on the line referenced above.
         This will require a general solution to anonymous modules because the
         argument to the functor application is a module expression that 
         includes the module core.Time_ns.Span.T.

   - Core_kernel__Float.[abs,neg,of_int]
         lib/core_kernel/src/time_float0.ml, line 7, characters 3-8
       This is a bug:
         The dependency
           core_kernel.Float:abs -> foo
         should generate the dependency
           core_kernel.Float.O:abs -> foo
         which, in turn, should generate the dependency
           base.Float.O:abs -> foo
         The first dependency in this chain should be generated by the module
         type include on line lib/core_kernel/src/time_float0.ml:10 in the 
         module type annotation that begins on the line referenced above. 
         However the module type that is included is obtained via a module type
         extraction: include module type of struct include Float.O end.

   - Core_kernel__Hash_set.fold
         lib/base/src/container.ml, line 89, characters 6-792
       This is a bug:
         The dependency
           base.Container_intf%Generic:fold -> foo
         should generate the dependency
           base.Container#Make_gen:fold -> foo
         because the functor has a signature module type annotation in which the
         interface is included.

   - Core_kernel__Set.of_map_keys
         lib/core_kernel/src/std_internal.ml, line 205, characters 8-11
       This is a bug:
         Due to not handling local module declarations in expressions. On lines
         lib/core_kernel/src/std_internal.ml:183--205 a local module is defined
         as an alias of core_kernel.Set, with a module type annotation 
         consisting of a signature which includes various interfaces. Thus, the
         dependency
           core_kernel.Set:of_map_keys -> foo
         should generate the dependency
           core_kernel.Set_intf%Creators2_with_comparator:of_map_keys -> foo

   - Ppx_core__Ast_builder.Default.[
         eabstract,eapply,ebool,echar,econstruct,efloat,eint,elist,enativeint,
         esequence,estring,eta_reduce_if_possible,
         eta_reduce_if_possible_and_nonrec,eunit,evar,pbool,pchar,pconstruct,
         pexp_tuple_opt,pfloat,pint,plist,pnativeint,ppat_tuple_opt,
         pstr_value_list,pstring,punit,pvar,type_constr_conv,
         unapplied_type_constr_conv
       ]
         ppx/ppx_core/src/ast_builder.ml, line 234, characters 54-2426
       This is a bug:
         The dependency
           ppx_core.Ast_builder_intf%Additional_helpers:eabstract -> foo
         should generate the dependency
           ppx_core.Ast_builder_intf%S:eabstract -> foo
         due to the signature include on line
           ppx/ppx_core/src/ast_builder_intf.ml:133
         It is not clear why this is not happening.

--------------------------------------------------------------------------------
3. Syntax error (7) [3 distinct symptoms]

   - Base__Hash.create: 
         lib/core_kernel/src/float_with_finite_only_serialization::10,4--10,45
       Ghost location not flagged, location of type declaration reused.

   - Bin_prot__Shape.Expression.[rec_app,record,top_app,tuple,variant]:
         lib/bin_prot/shape/src/bin_shape.ml:461,2--472,32
       Ghost location not flagged, location of type declaration reused.
       In these cases, value to be renamed is automatically PPX generated.

   - Expect_test_matcher__Cst.Line.compare:
       Ghost location not flagged, location of type delaration reused.
       In this case, value to be renamed is automatically PPX generated.

--------------------------------------------------------------------------------
4. The function applied to this argument has type [...] This argument cannot be applied with label [...] [1 distinct symptom]

   - Core_kernel__Thread_safe_queue.length
         lib/core_kernel/src/thread_safe_queue.ml:75,12--75,18
       Ghost location not flagged, location of field name declaration reused.
       In this case, value to be renamed is automatically PPX generated.

--------------------------------------------------------------------------------
5. The implementation [...] does not match the interface [...] [35 distinct symptoms]

**** These seem to be due to dependencies that are failing to be generated by
**** interface annotations. Some of these are declared in .mli files but not
**** mirrored in the corresponding .ml files. The interfaces are modified by
**** 'with' clauses: could this be the reason they are not generated?

   - Core_kernel__Comparator.Poly.comparator
         lib/base/src/comparator.ml
       This is a bug:
         The dependency
           base.Comparator%S1:comparator -> foo
         should generate the dependency
           base.Comparator#S_to_S1:comparator -> foo
         due to the interface annotation on line
           lib/base/src/comparator.mli:45

   - Base__List.mem
   - Core_kernel__Array.mem
   - Core_kernel__List.mem
         lib/base/src/container.ml
       This is a bug:
         The dependency
           base.Container_intf%S1:mem -> foo
         should generate the dependency
           base.Container_intf#Make:mem -> foo
         due to the interface annotation on line
           lib/base/src/container_intf.ml:478

   - Core_kernel__String.mem
         lib/base/src/container.ml
       This is a bug:
         The dependency
           base.Container_intf%S0:mem -> foo
         should generate the dependency
           base.Container_intf#Make0:mem -> foo
         due to the interface annotation on line
           lib/base/src/container_intf.ml:479

   - Core__Iobuf.invariant
   - Core_kernel__Bounded_int_table.invariant
         lib/base/src/either.ml
       This is a bug:
         The dependency
           base.Invariant%S2:invariant -> foo
         should generate the dependency
           base.Either_intf%Either:invariant -> foo
         due to the module type include on line
           lib/base/src/either_intf.ml:61

   - Base__Float.to_string
         lib/base/src/float.ml
       This is a bug:
         There is a local declaration of the value 'to_string' which is renamed
         correctly in the file
           lib/base/src/float.mli
         However the interface base.Identifiable%S is included by the .mli file
         and this also contains a declaration of the value 'to_string'
         ***** IMPROPER HANDLING OF SHADOWING *****
       see also Base__List.map below

   - Core_kernel__Int.Hash_set.[create,of_list]
         lib/base/src/hash_set.ml
       This is a bug:
         The dependency
           base.Hash_set_intf%Creators:[...] -> foo
         should generate the dependency
           base.Hash_set:[...] -> foo
         due to the include on line
           lib/base/src/hash_set.mli:18

   - Base__Hashtbl.Poly.of_alist
   - Base__Hashtbl.Using_hashable.[clear,copy,equal,existsi,filteri,fold,
         is_empty,iter_keys,keys,length,map,mapi,mem,remove,set,clear
       ]
   - Core_kernel__Hashtbl.[find,find_exn,find_or_add,fold,iteri,length,mem,
         remove,set,to_alist
       ]
   - Core_kernel__Int.Table.of_alist_exn
   - Core_kernel__String.Table.of_alist_exn
         lib/base/src/hashtbl.ml
       This is a bug:
         The dependency
           base.Hashtbl_intf%Creators[...] -> foo
         should generate the dependencies
           base.Hashtbl_intf%S_without_submodules[...] -> foo
           base.Hashtbl_intf%S_using_hashable[...] -> foo
           base.Hashtbl_intf%S_poly[...] -> foo
         due to the includes on lines
           lib/base/src/hashtbl_intf.ml:371
           lib/base/src/hashtbl_intf.ml:396
           lib/base/src/hashtbl_intf.ml:424
           lib/base/src/hashtbl_intf.ml:447
         which, in turn, should generate the dependencies
           base.Hashtbl_intf%Hashtbl[...] -> foo
           base.Hashtbl_intf%Hashtbl#Creators[...] -> foo
           base.Hashtbl_intf%Hashtbl.Using_hashable[...] -> foo
           base.Hashtbl_intf%Hashtbl.Poly[...] -> foo

   - Base__Int.[bit_and,incr,max_value,min_value,num_bits,pred,
         shift_right_logical
       ]
   - Core_kernel__Import.[land,lor,lsl,lsr,max_value,min_value,num_bits,pred,
         rem,succ
       ]
         lib/base/src/int64.ml
         lib/base/src/int32.ml
         lib/base/src/nativeint.ml
       This is a bug:
         The dependency
           base.Int_intf%S:[...] -> foo
         should generate the dependencies
           base.Int32:[...] -> foo
           base.Int63:[...] -> foo
           base.Int64:[...] -> foo
           base.Nativeint:[...] -> foo
         due to the respective interface includes on lines
           /lib/base/src/int32.mli:14
           /lib/base/src/int63.mli:17
           /lib/base/src/int64.mli:3
           /lib/base/src/nativeint.mli:3
         These should respectively generate the dependencies
           core_kernel.Int32:[...] -> foo
           core_kernel.Int63:[...] -> foo
           core_kernel.Int64:[...] -> foo
           core_kernel.Nativeint:[...] -> foo
         due to the module type includes on lines
           /lib/core_kernel/src/int32.mli:1
           /lib/core_kernel/src/int63.mli:1
           /lib/core_kernel/src/int64.mli:1
           /lib/core_kernel/src/nativeint.mli:1
         which are of the form, e.g.
           include module type of struct include Base.Int64 end
             with module Hex := Base.Int64.Hex
         and also the module includes on lines
           /lib/core_kernel/src/int32.ml:15
           /lib/core_kernel/src/int63.ml:61
           /lib/core_kernel/src/int64.ml:15
           /lib/core_kernel/src/nativeint.ml:15
         which are of the form, e.g.
           include (Base.Int32 : (module type of struct include Base.Int32 end
                                   with type t := t and module Mex := Hex))

   - Core_kernel__Queue.enqueue
         lib/base/src/linked_queue.ml
       This is a bug:
         The dependency
           base.Queue_intf%S:enqueue -> foo
         should generate the dependency
           base.Linked_queue:enqueue -> foo
         due to the interface include on line
           lib/base/src/linked_queue.mli:7

   - Base__Lazy.map
   - Base__Option.map
   - Base__Or_Error.map
   - Base__Result.map
   - Core_kernel__Option.map
   - Core_kernel__Or_error.map
   - Core_kernel__Quickcheck.Generator.map
   - Core_kernel__Result.map
   - Core_kernel__Sequence.map
         The implementation lib/base/src/list.ml
       This is a bug:
         The dependency
           base.Monad%S:map -> foo
         should generate the dependency
           base.List:map -> foo
         due to the interface include on line
           /lib/base/src/list.mli:23

   - Base__List.map
   - Core_kernel__List.map
         lib/base/src/list.ml
       This is a bug:
         There is a local declaration of the value 'map' which is renamed
         correctly in the file
           lib/base/src/list.mli
         However the interface base.Monad%S is included by the .mli file
         and this also contains a declaration of the value 'map'.
   - Core_kernel__List.count
         lib/base/src/list.ml
       This is a bug:
         There is a local declaration of the value 'count' which is renamed
         correctly in the file
           lib/base/src/list.mli
         However the interface base.Container_intf%S1 is included by the .mli
         file and this also contains a declaration of the value 'count'.
         ***** IMPROPER HANDLING OF SHADOWING *****
       see also Base__Float.to_string above

   - Base__Hashtbl.invariant
   - Core_kernel__Option.Let_syntax.Let_syntax.map
   - Core_kernel__Pool.Unsafe.invariant
   - Core_kernel__Quickcheck.Let_syntax.Let_syntax.[bind,both,map]
   - Core_kernel__Quickcheck.Let_syntax.return
   - Core_kernel__Timing_wheel_ns.invariant
         lib/base/src/or_error.ml
       This is a bug:
         The dependencies
           base.Invariant_intf%S1:invariant
           base.Monad_intf%S.Let_syntax.return
           base.Monad_intf%S.Let_syntax.Let_syntax:[...] -> foo
         should, respectively, generate the dependencies
           base.Or_error:invariant -> foo
           base.Or_error.Let_syntax.return -> foo
           base.Or_error.Let_syntax.Let_syntax:[...] -> foo
         due to the respective signature includes on line
           lib/base/src/or_error.mli:30
           lib/base/src/or_error.mli:31

   - Core__Core_unix.File_descr.equal
         lib/base/src/ordering.ml
       This is a bug:
         The dependency
           base.Equal%S:equal -> foo
         should generate the dependency
           base.Ordering:equal -> foo
         due to the signature include on line
           lib/base/src/ordering.mli:43

   - Base__String.[is_empty,length]
   - Core_kernel__String.[is_empty,length]
         lib/base/src/string.ml
       This is an unshadowing bug:
         There are local declarations of the values 'is_empty' and 'length' 
         which are renamed correctly in the file
           lib/base/src/string.mli
         However the interface base.Container_intf%S0 is included by the .mli
         file and this also contains declaration of these values.

   - Base__Error.invariant
         lib/base/src/unit.ml
       This is a bug:
         The dependency
           base.Invariant_intf%S:invariant
         should generate the dependency
           base.Error:invariant -> foo
         due to the signature include on line
           lib/base/src/error.mli:20

   - Bin_shape_lib__Bin_shape.Location.of_string
         lib/bin_prot/shape/src/bin_shape.ml
       This is a bug:
         The dependencies
           bin_shape_lib.Core_fragment.String:of_string -> foo
           bin_shape_lib.Core_fragment.Identifiable%S:of_string -> foo
         should both generate the dependencies
           bin_shape_lib.Bin_shape.Uuid:of_string -> foo
           bin_shape_lib.Bin_shape.Tid:of_string -> foo
           bin_shape_lib.Bin_shape.Vid:of_string -> foo
         due, respectively, to the module includes on lines
           lib/bin_prot/shape/src/bin_shape.ml:12
           lib/bin_prot/shape/src/bin_shape.ml:406
           lib/bin_prot/shape/src/bin_shape.ml:412
         and the signature includes on lines
           lib/bin_prot/shape/src/bin_shape.ml:10
           lib/bin_prot/shape/src/bin_shape.ml:404
           lib/bin_prot/shape/src/bin_shape.ml:410

   - Base_Array.max_length
         lib/core_kernel/src/array.ml
       This is a bug:
         The dependency
           base.Array:max_length -> foo
         should generate the dependency
           core_kernel.Array:max_length -> foo
         due to the signature include on line
           lib/core_kernel/src/array.mli:7
         However the signature is obtain via module type extraction:
           include module type of struct include Base.Array end with type 'a t := 'a t
   - Core_kernel__Array.max_length
         lib/core_kernel/src/array.ml
       This is a bug:
         The dependency
           core_kernel.Array:max_length -> foo
         should generate the dependency
           base.Array:max_length -> foo
         due to the signature include on line
           lib/core_kernel/src/array.mli:7
         However the signature is obtain via module type extraction:
           include module type of struct include Base.Array end with type 'a t := 'a t

   - Core_kernel__Bool.[gen,obs,shrinker]
   - Core_kernel__Int.gen
   - Core_kernel__String.[gen,obs]
         lib/core_kernel/src/bool.ml
       This is a bug:
         The dependency
           core_kernel.Quickcheckable%S:gen -> foo
         should generate the dependency
           core_kernel.Bool:gen -> foo
         due to the signature include on line
           lib/core_kernel/src/bool.mli:12
   - Core_kernel__Bool.gen
         lib/core_kernel/src/char.ml
         lib/core_kernel/src/unit.ml
       This is a bug:
         The dependency
           core_kernel.Quickcheckable%S:gen -> foo
         should generate, respectively, the dependencies
           core_kernel.Char:gen -> foo
           core_kernel.Unit:gen -> foo
         due to the respective signature includes on line
           lib/core_kernel/src/char.mli:12
           lib/core_kernel/src/unit.mli:14
     *****
     What is interesting about this is that the signature include
       include Quickcheckable.S with type t := t 
     *does* generate the dependency
       core_kernel.Quickcheckable%S.gen -> foo
     for the target renaming, e.g. if the target renaming is
       core_kernel.Bool:gen -> foo
     then the include in bool.mli does generate the dependency
       core_kernel.Quickcheckable%S.gen -> foo
     but this dependency does not then cascade to the other modules whose .mli
     files include it.
     *****

   - Core_kernel__Linked_queue.[clear,create,dequeue_exn,enqueue]
         lib/core_kernel/src/queue.ml
       This is a bug:
         The dependency
           base.Queue_intf%S:clear -> foo
         should generate the dependency
           core_kernel.Queue_intf%S:clear -> foo
         due to the include on line
           lib/core_kernel/src/queue_intf.ml:6
         which, in turn, should generate then dependency
           core_kernel.Queue:clear -> foo
         due to the include on line
           lib/core_kernel/src/queue.mli:19

   - Core_kernel__queue.create
         lib/core_kernel/src/queue.ml
       This is an unshadowing bug:
         There is a local declaration of the value 'create' 
         which is renamed correctly in the file
           lib/core_kernel/src/queue.mli
         However the interface core_kernel.Queue_intf%S is included by the .mli
         file and this also contains declaration of this value.

   - Core_kernel__Time_float.Span.[of_int_sec,of_ns,of_sec,to_sec]
         lib/core_kernel/src/span.ml
       This is a bug:
         The dependency
           core_kernel.Span_intf%Span:[...] -> foo
         should generate the dependency
           core_kernel.Span:[...] -> foo
         due to the signature include on line
           lib/core_kernel/src/span.mli:1

   - Core_kernel__Time_float.[now,of_span_since_epoch,to_span_since_epoch]
         lib/core_kernel/src/time_float0.ml
       This is a bug:
         The dependency
           core_kernel.Time0_intf%S:[...]
         should generate the dependency
           core_kernel.Time_float0:[...] -> foo
         due to the signature include on line
           lib/core_kernel/src/time_float0.mli:1

   - Core__Core_time_float.[
         abs_diff,diff,now,occurrence,of_date_ofday,of_filename_string,to_date,
         to_date_ofday,to_filename_string,to_sec_string,to_string_abs
       ]
         lib/core_kernel/src/time.ml
       This is a bug:
         The dependency
           core_kernel.Time_intf%S:abs_diff -> foo
         should generate the dependency
           core_kernel.Time_intf#Make:abs_diff -> foo
         due to the module type annotation for the functor on line
           lib/core_kernel/src/time_intf.mli:217
         which, in turn, should generate the dependency
           core_kernel.Time#Make:abs_diff -> foo
         due to the signature include on line
           lib/core_kernel/src/time.mli:1
     
   - Core__Core_time_float.Zone.next_clock_shift
         lib/core_kernel/src/zone.ml
       This is a bug:
         The dependency
           core_kernel.Zone_intf%S:next_clock_shift -> foo
         should generate the dependency
           core_kernel.Zone_intf#Make:next_clock_shift -> foo
         due to the module type annotation for the functor on line
           lib/core_kernel/src/zone_intf.mli:90
         which, in turn, should generate the dependency
           core_kernel.Zone#Make:next_clock_shift -> foo
         due to the signature include on line
           lib/core_kernel/src/zone.mli:1

   - Core__Command.Param.flag
       	 lib/core/src/command.ml
       This is a bug:
         The dependency
           core.Command.Param%S:flag -> foo
         should generate the dependency
           core.Command.Spec:flag -> foo
         due to the signature include on line
           lib/core/src/command.mli:372

   - Core__Iobuf.[
         advance,bin_prot_length_prefix_bytes,bounded_compact,bounded_flip_hi,
         bounded_flip_lo,capacity,compact,consume_bin_prot,create,fill_bin_prot,
         flip_hi,flip_lo,input,is_empty,length,narrow,narrow_hi,narrow_lo,
         no_seek,of_bigstring,of_string,output,pread_assume_fd_is_nonblocking,
         protect_window_and_bounds,pwrite_assume_fd_is_nonblocking,read,
         read_assume_fd_is_nonblocking,read_only,
         recvfrom_assume_fd_is_nonblocking,recvmmsg_assume_fd_is_nonblocking,
         reset,resize,rewind,send_nonblocking_no_sigpipe,
         sendto_nonblocking_no_sigpipe,set_bounds_and_buffer,
         set_bounds_and_buffer_sub,sub_shared,to_string,to_string_hum,
         unsafe_advance,unsafe_resize,write,write_assume_fd_is_nonblocking
       ]
   - Core__Iobuf.Blit_consume_and_fill.[blit,blito,unsafe_blit]
   - Core__Iobuf.Blit_consume.[blit,blito,sub,subo,unsafe_blit]
   - Core__Iobuf.Blit_fill.[blit,blito,unsafe_blit]
   - Core__Iobuf.Expert.[
         buf,hi,hi_max,lo,lo_min,set_bounds_and_buffer,
         set_bounds_and_buffer_sub,to_bigstring_shared,to_iovec_shared
       ]
         lib/core/src/iobuf_debug.ml
       This is a bug:
         The dependency
           core.Iobuf[...] -> foo
         should generate the dependency
           core.Iobuf_debug[...]
         due to the signature include on line
           lib/core/src/iobuf_debug.mli:14
         This uses module type extraction:
           include module type of struct include Iobuf end

   - Core__Iobuf.[Consume,Fill,Peek,Poke].[
         bigstring,bigstringo,bin_prot,char,head_padded_fixed_string,string
         stringo,tail_padded_fixed_string
       ]
         lib/core/src/iobuf.ml
       This is a bug:
         The dependency
           core.Iobuf_intf%Accessors:[...] -> foo
         should generate the dependencies
           core.Iobuf.Consume:[...] -> foo
           core.Iobuf.Fill:[...] -> foo
           core.Iobuf.Peek:[...] -> foo
           core.Iobuf.Poke:[...] -> foo
         due to the signature includes on lines
           lib/core/src/iobuf.mli:253
           lib/core/src/iobuf.mli:262
           lib/core/src/iobuf.mli:292
           lib/core/src/iobuf.mli:306
   - Core__Iobuf.Fill.decimal
   - Core__Iobuf.Peek.index
   - Core__Iobuf.Poke.decimal
         lib/core/src/iobuf.ml
       This is a bug:
         The dependencies
           core.Iobuf.Consume:[...] -> foo
           core.Iobuf.Fill:[...] -> foo
           core.Iobuf.Peek:[...] -> foo
           core.Iobuf.Poke:[...] -> foo
         should generate the dependencies
           core.Iobuf.Unsafe.Consume:[...] -> foo
           core.Iobuf.Unsafe.Fill:[...] -> foo
           core.Iobuf.Unsafe.Peek:[...] -> foo
           core.Iobuf.Unsafe.Poke:[...] -> foo
         due to the signature includes on lines
           lib/core/src/iobuf.mli:315--318
         These use module type extraction:
           module Consume : module type of Consume
           module Fill    : module type of Fill
           module Peek    : module type of Peek
           module Poke    : module type of Poke
   - Core__Iobuf.Unsafe.[Consume,Fill,Peek,Poke].[
         bigstring,bigstringo,bin_prot,char,head_padded_fixed_string,string
         stringo,tail_padded_fixed_string
       ]
   - Core__Iobuf.Unsafe.Fill.decimal
   - Core__Iobuf.Unsafe.Peek.index
   - Core__Iobuf.Unsafe.Poke.decimal
         lib/core/src/iobuf.ml
       This is a bug:
         The dependency
           core.Iobuf.Unsafe.[...]:[...] -> foo
         should generate the dependency
           core.Iobuf.[...]:[..] -> foo
         due to one of the signature includes on lines
           lib/core/src/iobuf.mli:315--318

   - Core__Signal.to_string
         lib/core/src/signal.ml
       This is an unshadowing bug:
         There is a local declaration of the value 'to_string'
         which is renamed correctly in the file
           lib/core/src/signal.mli
         However the interface core_kernel.Stringable%S is included by the .mli
         file and this also contains declaration of this value.

   - Core_kernel__Timing_wheel_ns.[add,add_at_interval_num,advance_clock,
         alarm_precision,clear,create,fire_past_alarms,interval_num,
         interval_num_start,interval_start,is_empty,iter,length,
         max_alarm_time_in_min_interval,max_alarm_time_in_min_interval_exn,
         mem,min_alarm_interval_num,min_alarm_interval_num_exn,
         next_alarm_fires_at,next_alarm_fires_at_exn,now_interval_num,remove,
         reschedule,reschedule_at_interval_num
       ]
         lib/core/src/timing_wheel_float.ml
       This is a bug:
         The dependency
           core_kernel.Timing_wheel_ns_intf%Timing_wheel:[...] -> foo
         should generate the dependency
           core.Timing_wheel_float:[...] -> foo
         due to the signature include on line
           lib/core/src/timing_wheel_float.mli:23

   - Sexplib__Lexer.[main,main_with_layout]
         lib/sexplib/src/lexer.ml
       The source implementation of this module is a .mll file

   - Base__Sexp.[pp_hum,to_string,to_string_hum,to_string_mach]
   - Core_kernel__Sexp.[pp_hum,to_string,to_string_hum,to_string_mach]
         lib/sexplib/src/sexp.ml
       This is a bug:
         The dependency
           sexplib.Pre_sexp:pp_hum -> foo
         should generate the dependency
           sexplib.Sexp:pp_hum -> foo
         due to the module include on line
           lib/sexplib/src/sexp.ml:1
         which, in turn, should generate the dependency
           sexplib.Sexp_intf%S:pp_hum -> foo
         due to the signature include on line
           lib/sexplib/src/sexp.mli:3

   - Expect_test_collector__Check_backtraces.contains_backtraces
         ppx/ppx_expect/collector/check_backtraces.ml
       The source implementation of this module is a .mll file

   - Expect_test_matcher__Fmt.compare
         ppx/ppx_expect/matcher/fmt.ml
       The value to be renamed is PPX generated

   - Expect_test_matcher__Lexer.[extract_quoted_string_terminators,
         parse_body,parse_pretty,parse_pretty_line,strip_surrounding_whitespaces
       ]
         ppx/ppx_expect/matcher/lexer.ml
       The source implementation of this module is a .mll file


--------------------------------------------------------------------------------
6. The signature constrained by `with' has no component named t [1 distinct symptom]

   - Base__Array.compare
   - Core_kernel__Array.compare
         lib/core_kernel/src/array.ml:9,19--9,20
       Ghost location not flagged, location of type declaration reused.
       In these cases, value to be renamed is automatically PPX generated.

--------------------------------------------------------------------------------
7. This expression has type [...] [4 distinct symptoms]

   - Ppx_core__Ast_pattern.estring
   - Ppx_type_conv__Type_conv.Args.estring
         ppx/ppx_bin_prot/bin_shape_expand.ml:178,79--178,85
         ppx/ppx_bin_prot/bin_shape_expand.ml:179,65--179,71
       This is a bug:
         Identifiers are not being renamed.

   - Base__Import.lxor
   - Base__Import.asr
   - Base__Import.land
   - Base__Import.lor
   - Base__Import.lsl
   - Base__Import.mod
       This is a bug:
         These identifiers are OCaml infix keywords, so they need to be treated
         specially

   - Core__Import.phys_equal
   - Core_kernel__Std_import.phys_equal
         lib/core_kernel/src/univ_map.ml:140,27--140,30
       This is a bug:
         A value named "foo" is already in scope here! We need to do a soundness
         check.
         ***** IMPROPER HANDLING OF SHADOWING *****

   - Core_kernel__Month.of_int_exn
         lib/core_kernel/src/month.ml:138,18--138,28
       This is a bug:
         identifier is missed because it occurs in an anonymous module:
         specifically, in a functor argument module expression, in an include
         declaration

--------------------------------------------------------------------------------
8. This function has type [...] [1 distinct symptom]

   - Base__Import.lxor
       This identifier is an OCaml infix keyword, so needs to be treated 
       specially

--------------------------------------------------------------------------------
9. Unbound record field [...] [2 distinct symptoms]

   - Core_kernel__Timing_wheel_ns.alarm_upper_bound
   - Core_kernel__Timing_wheel_ns.now
   - Core_kernel__Timing_wheel_ns.start
         lib/core_kernel/src/timing_wheel_ns.ml:1220,12--1220,29
       Ghost location not flagged, location of field name declaration reused.
       In this case, value to be renamed is automatically PPX generated.

   - Core_kernel__Import.ref
   - Ppx_core__Import.ref
   - Ppx_driver__Import.ref
         ppx/ppx_expect/common/file.ml:30,4--37,30
         ppx/ppx_expect/common/file.ml:31,8--31,16
         ppx/ppx_expect/common/file.ml:32,8--32,19
         ppx/ppx_expect/common/file.ml:33,8--33,18
         ppx/ppx_expect/common/file.ml:34,8--34,17
         ppx/ppx_expect/common/file.ml:35,8--35,15
       Ghost locations not flagged, location of type declaration reused.

--------------------------------------------------------------------------------
10. Unbound type constructor [...] [12 distinct symptoms]

   Ultimately, these are all to do with PPX generated values.

   - Base__List.compare
   - Core_kernel__List.compare
         lib/core_kernel/src/list0.ml:31,26--31,27
       Ghost location not flagged, location of type declaration reused.

   - Base__Option.compare
   - Core_kernel__Option.compare
         lib/core_kernel/src/option.ml:9,26--9,27
       Ghost location not flagged, location of type declaration reused.

   - Base__Lazy.compare
   - Core_kernel__Lazy.compare
         lib/core_kernel/src/std_internal.ml:99,22--99,33
       Ghost location not flagged, location of type definition reused.

   - Base__Ref.compare
   - Core_kernel__Ref.compare
         lib/core_kernel/src/std_internal.ml:104,22--104,33
       Ghost location not flagged, location of type definition reused.

   - Base__Result.compare
   - Core_kernel__Result.compare
         lib/core_kernel/src/sexp.ml:29,35--29,43
       Ghost location not flagged, location of type definition reused.

   - Core__Core_time_float.Span.compare
         lib/core_kernel/src/timing_wheel_ns_intf.ml:88,9--88,10
       Ghost location not flagged, location of type definition reused.
       In this case, dependent value to be renamed is automatically PPX 
       generated.

   - Core_kernel__Queue.compare
         lib/core_kernel/src/queue.mli:17,8--17,9
       Ghost location not flagged, location of type definition reused.
       In this case, value to be renamed is automatically PPX generated.

   - Expect_test_common__Expectation.Body.compare
         ppx/ppx_expect/common/expectation.mli:2,10--2,11
       Ghost location not flagged, location of type definition reused.
       In this case, value to be renamed is automatically PPX generated.

   - Expect_text_common__File.Digest.compare
         ppx/ppx_expect/common/file.mli:28,7--28,8
       Ghost location not flagged, location of type definition reused.
       In this case, value to be renamed is automatically PPX generated.

   - Expect_test_matcher__Cst.compare
         ppx/ppx_expect/matcher/cst.mli:98,8--98,9
       Ghost location not flagged, location of type definition reused.
       In this case, value to be renamed is automatically PPX generated.

   - Core_kernel__Import.raise
   - Ppx_core__Import.raise
   - Ppx_driver__Import.raise
         lib/core_kernel/src/perms.ml:20,13--20,22
       Ghost location not flagged, location of type definition reused.

   - Core_kernel__Import.failwith
   - Ppx_core__Import.failwith
         lib/core_kernel/src/perms.ml:10,4--10,51
         lib/core_kernel/src/perms.ml:15,4--15,51
       Ghost location not flagged, location of type declaration reused.

--------------------------------------------------------------------------------
11. Unbound value [...] [~25 distinct symptoms]

   - Ppx_core__Ast_Pattern.__
   - Ppx_type_conv__Type_conv.Args.[__,arg]
         ppx/ppx_bin_prot/shape/src/bin_shape_expand.ml:178, Unbound value __
       This is a bug:
         The file
           ppx/ppx_bin_prot/shape/src/bin_shape_expand.ml
         should depend on the file
           ppx/ppx_core/src/ast_pattern.ml(i)
         due to the identifiers on lines
           ppx/ppx_bin_prot/shape/src/bin_shape_expand.ml:178
           ppx/ppx_bin_prot/shape/src/bin_shape_expand.ml:179

   - Sexplib__Src_pos.Absolute.[add,geq]
         lib/sexplib/src/sexp_with_layout.ml:71, Unbound value Abs_pos.add
         lib/sexplib/src/sexp_with_layout.ml:83, Unbound value Abs_pos.geq
         lib/sexplib/src/sexp_with_layout.ml:129, Unbound value Abs_pos.sub
       This is a bug:
         The dependency
           sexplib.Src_pos.Absolute:[...] -> foo
         should generate the dependency
           sexplib.Sexp_with_layout.Render.Abs_pos:[...] -> foo
         due to the module alias on line
           lib/sexplib/src/sexp_with_layout.ml:22

   - Core_kernel__Quickcheck.Generator.[all,return]
         lib/base/src/list.ml:594, Unbound value all
         lib/base/src/list.ml:593, Unbound value return
   - Core_kernel__Option.bind
         lib/base/src/list.ml:591, Unbound value bind
   - Core_kernel__Option.[join,return]
         lib/base/src/list.ml:590, Unbound value join
         lib/base/src/list.ml:593, Unbound value return
   - Base__Result.return
         lib/base/src/list.ml:593, Unbound value return
       This is as-yet unsupported:
         The value to be renamed occurs in an anonymous module, and is 
         introduced into its scope via a functor application within this
         anonymous module, i.e. this requires generating a dependency that 
         operates *within* an anonoymous module.

   - Base__Array.get
   - Core_kernel__Array.get
         lib/base/src/array0.ml:59, Unbound value Array.get
   - Base__String.get
   - Core_kernel__String.get
         lib/base/src/sexp.ml:66, Unbound value String.get
   - Base__Array.set
   - Core_kernel__Array.set
         lib/base/src/array0.ml:60, Unbound value Array.set
       The value comes from desugared array access syntax:
         tmp = t.(i)
         t.(i) <- t.(j)
       and there is a locally defined Array module in scope at this point, which
       contains a declaration of the value that has been renamed.
       *******
       This is interesting - what do we do about this, because we cannot change
       how native syntax is desugared by the compiler.
       *******

   - Core_kernel__Timing_wheel_ns.Alarm.at
         lib/core/src/timing_wheel_float.ml:50, Unbound value at
       This is two bugs:
         An include of the module core_kernel.Timing_wheel_ns.Alarm on line
           lib/core/src/timing_wheel_float.ml:48
         does not seem to generate a local renaming in the remainder of the
         scope.
         It also generates the dependency
           core.Timing_wheel_float.Alarm:at -> foo
         However this is a bogus dependency because there is a redeclaration of
         the value 'at' later in the scope.
         ***** IMPROPER HANDLING OF SHADOWING *****

   - Core__Iobuf.Consume.bigstring
         lib/core/src/iobuf_debug.ml":385, Unbound value bigstring
   - Core__Iobuf.Fill.bin_prot
         lib/core/src/iobuf_debug.ml:329, Unbound value bin_prot
   - Core__Iobuf.Consume.tail_padded_fixed_string
         lib/core/src/iobuf_debug.ml:367, Unbound value tail_padded_fixed_string
       This is a duplicate bug, detailed above:
         The dependency
           core.Iobuf_intf%Accessors:[...] -> foo
         should generate the dependencies
           core.Iobuf.Consume:[...] -> foo
           core.Iobuf.Fill:[...] -> foo
           core.Iobuf.Peek:[...] -> foo
           core.Iobuf.Poke:[...] -> foo
         due to the signature includes on lines
           lib/core/src/iobuf.mli:253
           lib/core/src/iobuf.mli:262
           lib/core/src/iobuf.mli:292
           lib/core/src/iobuf.mli:306
   - Core__Iobuf.Unsafe.Consume.[bigstring,head_padded_fixed_string]
         lib/core/src/iobuf_debug.ml:1007, Unbound value foo
         lib/core/src/iobuf_debug.ml:995, Unbound value foo
   - Core__Iobuf.Unsafe.Fill.[bigstring,tail_padded_fixed_string]
         lib/core/src/iobuf_debug.ml:1079, Unbound value foo
         lib/core/src/iobuf_debug.ml1061, Unbound value foo
   - Core__Iobuf.Unsafe.Peek.string
         lib/core/src/iobuf_debug.ml:1155, Unbound value foo
       This is a duplicate bug, detailed above:
         The dependency
           core.Iobuf.Unsafe.[...]:[...] -> foo
         should generate the dependency
           core.Iobuf.[...]:[..] -> foo
         due to one of the signature includes on lines
           lib/core/src/iobuf.mli:315--318
   - Core__Bigstring.sub_shared
         lib/core/src/iobuf.ml:927, Unbound value Bigstring.foo
       This is a bug:
         The dependency
           core.Bigstring:sub_shared -> foo
         should generate the dependency
           core_kernel.Bigstring:sub_shared -> foo
         due to the signature include on line
           lib/core/src/bigstring.mli:6
         However the signature is obtained via module type extraction:
           include module type of struct include Core_kernel.Bigstring end
   - Core__Comannd.Param.[optional_with_default,required]
         lib/core/src/schedule.ml:340, Unbound value foo
         lib/core/src/schedule.ml:338, Unbound value foo
       This is a bug:
         The dependency
           core.Command.Param:[...] -> foo
         should generate the dependency
           core.Command.Flag:[...] -> foo
         due to the signature include on line:
           lib/core/src/command.mli:342
         However the signature is obtained via module type extraction:
           include module type of Flag with type 'a t := 'a Flag.t
   - Ppx_core__Ast_builder.Default.[pexp_apply,pexp_tuple,ppat_tuple,ptyp_poly,
             ptyp_tuple
           ]
         ppx/ppx_let/src/ppx_let.ml:57
         ppx/ppx_metaquot/lifters/ppx_metaquot_lifters.ml:[15,42]
         ppx/ppx_optcomp/src/ppx_optcomp.ml:58
         ppx/ppx_hash/expander/ppx_hash_expander.ml:327
         ppx/ppx_typerep_conv/src/ppx_typerep_conv.ml:118
           Unbound value foo
       This is a bug:
         The dependency
	       ppx_core.Ast_builder.Default:[...] -> foo
         should generate the dependency
           ppx_core.Ast_builder_generated.M:[...] -> foo
         due to the signature include on line
           ppx/ppx_core/src/ast_builder.mli:84
         However the signature is ontained via module type extraction:
           include module type of Ast_builder_generated.M
       Notwithstanding, there is a further problem; namely that the module
         ppx_core.Ast_builder_generated
       is automatically generated.
   - Base__Error.of_string
   - Core_kernel__Error.of_string
         lib/core/src/command.ml:1860, Unbound value Info.of_string
       This is a bug:
         The dependency
           base.Info:of_string -> foo
         should generate the dependency
           core_kernel.Info_intf%Info:of_string
         due to the signature include on line
           lib/core_kernel/src/info_intf.ml:21
         However the signature is obtained via module type extraction:
           include module type of struct include Base.Info end
   - Base__Import.of_sexp_error
   - Base__Sexp_conv.of_sexp_error
   - Core__Import.of_sexp_error
   - Core_kernel__Import.of_sexp_error
   - Core_kernel__Std_import.of_sexp_error
   - Sexplib__Conv.of_sexp_error
         lib/sexplib/num/lib/sexplib_num_conv.ml:15, Unbound value of_sexp_error
       This is a bug:
         The dependency
           base.Base.Exported_for_specific_uses.Sexplib.Conv:of_sexp_error -> foo
         should generate the dependency
           sexplib.Conv:of_sexp_error -> foo
         due to the signature include on line
           lib/sexplib/num/lib/conv.mli:4
         However the signature is obtained via module type extraction:
           include module type of Base.Exported_for_specific_uses.Sexplib.Conv
  - Core_kernel__Source_code_position.to_string
        lib/core_kernel/src/debug.ml:50, Unbound value Source_code_position.foo
      This is a bug:
        The dependency
          core_kernel.Source_code_position:to_string -> foo
        should generate the dependency
          base.Source_code_position:to_string -> foo
        due to the signature include on line
          lib/core_kernel/src/source_code_position.mli:1
        However the signature is obtained via module type extraction
          include module type of struct include Base.Source_code_position end
   - Core__Core_time_float.Ofday.[create,of_string]
         lib/core/src/core_time.ml:384, Unbound value Ofday.foo
         lib/core/src/core_time.ml:520, Unbound value Ofday.foo
       This is a bug:
         The dependency
           core_kernel.Time_intf%S.Ofday:[...] -> foo
         should generate the dependency
           core_kernel.Time_intf%S.Time.Ofday:[...] -> foo
         due to the signature include on line
           lib/core_kernel/src/time_intf.ml:10
         which, for the create function, should in turn generate the dependency
           core_kernel.Time0_intf%S.Ofday:create -> foo
         and, for the of_string function, should in turn generate the dependency
           base.Stringable%S:to_string
         due to the open, include, and module aliases on, respectively, lines
           lib/core_kernel/src/ofday_intf.ml:2
           lib/core_kernel/src/std_internal.ml:12
           lib/core_kernel/src/interfaces.ml:24
   - Core__Core_time_float.Ofday.[compare,next,of_span_since_start_of_day,prev,
             start_of_day,to_parts,to_span_since_start_of_day
           ]
         lib/core/src/schedule.ml:130, Unbound value Time.Ofday.foo
         lib/core/src/schedule.ml:812, Unbound value Time.Ofday.foo
         lib/core/src/schedule.ml:505, Unbound value Time.Ofday.foo
         lib/core/src/schedule.ml:819, Unbound value Time.Ofday.foo
         lib/core/src/core_date.ml:17, Unbound value Time.Ofday.foo
         lib/core/src/schedule.ml:508, Unbound value Time.Ofday.foo
         lib/core/src/schedule.ml:484, Unbound value Time.Ofday.foo
       This is a bug:
         The dependency
           core.Core_time_intf%S.Ofday:compare -> foo
         should generate the dependency
           core.Core_time_intf%S.Time.Ofday:compare -> foo
         due to the signature include on line
           lib/core/src/core_time_inf.ml:85
         However, the signature is obtained via module type extraction
           include (module type of struct include Time.Ofday end)
         This dependency should then generate the dependency
           core_kernel.Time_intf%S.Ofday:compare -> foo
         which, as it happens, is generated via another route.
         Thence, the situation is similar to the cases above: this dependency
         should, in turn, generate the dependency
           core_kernel.Time_intf%S.Time.Ofday:compare -> foo
         due to the signature include on line
           lib/core_kernel/src/time_intf.ml:10
         However the signature is obtained via module type extraction:
           include (module type of struct include Time end)
         This dependency should, in turn generate the following dependency
           core_kernel.Time0_intf%S.Ofday:[..] -> foo
         due to the module type annotation on line
           lib/core_kernel/src/time_intf.ml:7
         which should,in turn, generate the dependency
           core_kernel.Ofday_intf%Ofday:[...]
         due to the module type annotation on line
           lib/core_kernel/src/time0_intf.ml:12
         For the compare function, the following further chain of dependencies
         should be generated
           core_kernel.Comparable%S_binable:compare -> foo
           core_kernel.Comparable%S_common:compare -> foo
           base.Comparable_intf%S:compare -> foo
           base.Comparisons%S:compare -> foo
   - Core__Core_time_float.Span.[day,min,of_day,to_sec,max,of_string,of_us,
             randomize,to_short_string,to_string
           ]
         lib/core/src/core_time.ml:440, Unbound value Span.foo
         lib/core/src/core_time.ml:459, Unbound value Span.foo
         lib/core/src/core_time.ml:424, Unbound value Span.foo
         lib/core/src/schedule.ml:763, Unbound value Time.Span.foo
         lib/core/src/command.ml:196, Unbound value Time.Span.foo
         lib/core/src/time_ns.ml:39, Unbound value Time.Span.foo
         lib/core/src/time_ns.ml:120, Unbound value Time.Span.foo
         lib/core/src/time_ns.ml:119, Unbound value Time.Span.foo
         lib/core/src/time_ns.ml:106, Unbound value Time.Span.foo
       This is a bug:
         The dependency
           core_kernel.Time_intf%S.Span:[...] -> foo
         should generate the dependency
           core_kernel.Time_intf%S.Time.Span:[...] -> foo
         due to the signature include on line
           lib/core_kernel/src/time_intf.ml:10
         which should in turn generate the dependency
           core_kernel.Time0_intf%S.Span:[...] -> foo
         which should in turn generate the dependency
           core_kernel.Span_intf%Span:[...] -> foo
         which, for the [min,max] functions 
         should in turn generate the following chain of dependencies
           core_kernel.Comparable%S_binable:[...] -> foo
           core_kernel.Comparable_intf%S_binable:[...] -> foo
           core_kernel.Comparable_intf%S_common:[...] -> foo
           base.Comparable_intf%S:[...] -> foo
           base.Comparisons%S:[...]
         However the signature is obtained via module type extraction:
           include (module type of struct include Time end)
   - Core__Core_time_float.[next,prev]
         lib/core/src/schedule.ml:853, Unbound value Time.foo
         lib/core/src/schedule.ml:1301, Unbound value Time.foo
       This is a bug:
         The dependency
           core_kernel.Time_intf%S:[...] -> foo
         should generate the dependency
           core_kernel.Time_intf%S.Time:[...] -> foo
         due to the signature include on line
           lib/core_kernel/src/time_intf.ml:10
         which should in turn generate the dependency
           core_kernel.Time0_intf%S:[...] -> foo
         However the signature is obtained via module type extraction:
           include (module type of struct include Time end)
   - Core_kernel__Time_float.to_date
         lib/core/src/time_ns.ml:336, Unbound value Time.to_date
       This is a bug:
         The dependency
           core.Core_time_intf%S:to_date -> foo
         should generate the dependency
           core.Core_time_intf%S.Time:to_date -> foo
         due to the signature include on line
           lib/core/src/core_time_intf.ml:120
         which should in turn generate the dependency
           core_kernel.Time_intf%S:to_date -> foo
         However the signature is obtained via module type extraction:
           include module type of Time with type t := t
                                        and module Zone := Zone and module Ofday := Ofday

   - Typerep_lib__Std_internal.Typerep.Tag.internal_use_only
         lib/typerep/lib/type_generic.ml:25, Unbound value B.Tag.internal_use_only
   - Typerep_lib__Std_internal.Typerep.Variant.internal_use_only
         lib/typerep/lib/type_generic.ml:48, Unbound value B.Variant.internal_use_only
       This is a bug:
         The dependencies
           typerep_lib.Variant_and_record_intf%S.[Tag,Variant]:internal_use_only -> foo
         should generate the dependencies
           typerep_lib.Type_generic#Helper[2].[Tag,Variant]:internal_use_only -> foo
         due to the module type annotation for the functor parameter on line
           lib/typerep/lib/type_generic.ml:5
   - Core_kernel__Option.bind
         lib/base/src/applicative.ml:97, Unbound value M.bind
       This is a bug:
         One (or more?) of the following dependencies:
           base.Monad%S.bind -> foo
           base.Monad_intf%S.bind -> foo
         should generate the dependency:
           base.Applicative#Of_monad[1].bind -> foo
         It seems the parent module identifier (base__Monad, base__Monad_intf)
         at lib/base/src/applicative.ml:97 is not being found during processing
         of the file.
   - Core_kernel__Pool.[capacity,create,free,get,grow,is_full,length,set,unsafe_free]
   - Core_kernel__Pool.Unsafe.[
         get,grow,is_full,max_capacity,pointer_is_valid,set
       ]
   - Core_kernel__Pool.Pointer.[is_null,null]
   - Core_kernel__Pool.Unsafe.Pointer.[is_null,null]
         lib/core_kernel/src/pool.ml:983, Unbound value capacity
         lib/core_kernel/src/pool.ml:973, Unbound value create
         lib/core_kernel/src/pool.ml:1003, Unbound value free
         lib/core_kernel/src/pool.ml:1043, Unbound value get
         lib/core_kernel/src/pool.ml:988, Unbound value grow
         lib/core_kernel/src/pool.ml:993, Unbound value is_full
         lib/core_kernel/src/pool.ml;922, Unbound value is_null
         lib/core_kernel/src/pool.ml:952, Unbound value length
         lib/core_kernel/src/pool.ml:978, Unbound value max_capacity
         lib/core_kernel/src/pool.ml:925, Unbound value null
         lib/core_kernel/src/pool.ml:968, Unbound value pointer_is_valid
         lib/core_kernel/src/pool.ml:1051, Unbound value set
         lib/core_kernel/src/pool.ml:998, Unbound value unsafe_free
       This is a bug:
         The dependency
           core_kernel.Pool_intf%S:[...] -> foo
         should generate the dependency:
           core_kernel.Pool#Debug[1]:[...] -> foo
         due to the module type annotation on the functor parameter on line
           lib/core_kernel/src/pool.ml:883
   - Core_kernel__Pool.Unsafe.Pointer.phys_equal
         lib/core_kernel/src/pool.ml:1076, Unbound value Pointer.phys_equal
       This is a bug:
         The dependency
           core_kernel.Pool_intf%S:[...] -> foo
         should generate the dependency:
           core_kernel.Pool#Error_check[1]:[...] -> foo
         due to the module type annotation on the functor parameter on line
           lib/core_kernel/src/pool.ml:1056
   - Base__String.create
   - Core__Bigstring.[create,get,length]
   - Core_kernel__Bigstring.[create,get,length,set]
   - Core_kernel__String.create
         lib/core_kernel/base_for_tests/src/test_blit.ml:191, Unbound value length
         lib/core_kernel/base_for_tests/src/test_blit.ml:192, Unbound value get
         lib/core_kernel/base_for_tests/src/test_blit.ml:194, Unbound value create
         lib/core_kernel/base_for_tests/src/test_blit.ml:193, Unbound value set
       This is a bug:
         The dependency
           base_for_tests.Test_blit%Sequence:[...] -> foo
         should generate the dependency
           base_for_tests.Test_blit#Test[2]:[...] -> foo
         due to the module type annotation on the functor parameter on line
           lib/core_kernel/base_for_tests/src/test_blit.ml:182
   - Base__Bool.of_string
   - Base__Int.of_string
   - Base__Nativeint.of_string
   - Core__Core_time_float.of_string
   - Core__Core_time_float.Ofday.Zoned.of_string
   - Core__Core_time_float.Zone.of_string
   - Core_kernel__Date.of_string
   - Core_kernel__Float.of_string
   - Core_kernel__Host_and_port.of_string
   - Core_kernel__Int.of_string
   - Core_kernel__Month.of_string
   - COre_kernel__Percent.of_string
         lib/base/src/sexpable.ml:125, Unbound value M.of_string
       This is a bug:
         The dependency
           base.Stringable%S:of_string -> foo
         should generate the dependency
           base.Sexpable#Of_stringable[1]:of_string -> foo
         due to the module type annotation on the functor parameter on line
           lib/base/src/sexpable.ml:121
   - Base__Bool.to_string
   - Base__Int.to_string
   - Base__Nativeint.to_string
   - Core__Core_time_float.to_string
   - Core__Core_Unix.File_descr.to_string
   - Core__Time_ns.Ofday.to_string
   - Core__Time_ns.of_string
   - Core_kernel__Int.to_string
   - Core_kernel__Month.to_string
   - Core_kernel__Percent.to_string
   - Core_kernel__Pid.to_string
         lib/base/src/sexpable.ml:130, Unbound value M.to_string
       This is a bug:
         The dependency
           base.Stringable%S:to_string -> foo
         should generate the dependency
           base.Sexpable#Of_stringable[1]:to_string -> foo
         due to the module type annotation on the functor parameter on line
           lib/base/src/sexpable.ml:121
   - Base__Lazy.map
   - Base__Option.map
   - Base__Or_error.map
   - Base__Result.map
   - Core_kernel__Option.map
   - Core_kernel__Or_error.map
   - Core_kernel__Quickcheck.Generator.map
   - Core_kernel__Result.map
   - Core_kernel__Sequence.map
         lib/base/src/applicative.ml:69, Unbound value map
       This is a bug:
         The dependency
           base.Applicative_intf%S2:map -> foo
         should generate the dependency
           base.Applicative#Make_args'[1]:map -> foo
         due to the module type annotation on the functor parameter on line
           lib/base/src/applicative.ml:54
   - Core_kernel__Span.to_sec
         lib/core_kernel/src/time.ml:401, Unbound value Span.to_sec
       This is a bug:
         The dependency
           core_kernel.Time0_intf%S.Span:to_sec
         should generate the dependency
           core_kernel.Time#Make[1].Span:to_sec -> foo
         due to the module type annotation on the functor parameter on line
           lib/core_kernel/src/time.ml:9

   - Core__Core_time_float.to_span_since_epoch
         lib/core/src/core_time.ml:423, Unbound value foo
       This is a bug:
         The dependency
           core_kernel.Time_intf%S:to_span_since_epoch -> foo
         should generate the dependency
           core_kernel.Time_intf%S.Time:to_span_since_epoch -> foo
         due to the module include on line:
           lib/core_kernel/src/time_intf.ml:10
         which should, in turn generate the dependency:
           core_kernel.Time0_intf%S:to_span_since_epoch -> foo
         due to the module type annotation on line:
           lib/core_kernel/src/time_intf.ml:7
         However, in the former, the signature is obtained via module type extraction:
           include (module type of struct include Time end)
   - Core__Iobuf.Unsafe.Consume.[bigstring,head_padded_fixed_string]
   - Core__Iobuf.Unsafe.Fill.[bigstring,tail_padded_fixed_string]
   - Core__Iobuf.Unsafe.Peek.string
         lib/core/src/iobuf_debug.ml:[995,1007,1061,1079,1155]
           Unbound value foo
       This is a bug:
         The dependency
           core.Iobuf.Unsafe.[...] -> foo
         should generate the dependency
           core.Iobuf.[...] -> foo
         due to the module type annotation[s] on line
           lib/core/src/iobuf.mli:[315-317]
         However the signature is obtained via module type extraction:
           module Consume : module type of Consume
           module Fill    : module type of Fill
           module Peek    : module type of Peek
   - Core__Core_time_float.to_date
         lib/core_kernel/src/date.ml:3, Unbound value Time_float.to_date
       This is a bug:
         The dependency
           core_kernel.Time_intf%Time%S:to_date -> foo
         should generate the dependency
           core_kernel.Time_intf%Time#Make:to_date -> foo
         due to the module type annotation on line
           lib/core_kernel/src/time_intf.ml:217

   - Ppx_core__Common.assert_no_attributes
         ppx/ppx_core/src/ast_pattern_generated.ml:73, Unbound value Common.assert_no_attributes
       This file is automatically generated during the build process, and the
       identifier being renamed (ppx_core.Common:assert_no_attributes) is hard-coded
       into the generation process:
         ppx/ppx_core/src/gen/gen_ast_pattern.ml:23

   - Ppx_ast__Docstrings.[add_docs_attrs,add_info_attrs,docstring_loc]
         ppx/ppx_ast/src/parser0.mly:874, Unbound value add_docs_attrs
         ppx/ppx_ast/src/parser0.mly:353, Unbound value add_info_attrs
         ppx/ppx_ast/src/lexer.mll:237, Unbound value Docstrings.docstring_loc
   - Ppx_ast__Warn.care_about_ite_branch
         ppx/ppx_ast/src/parser0.mly:368, Unbound value Warn.care_about_ite_branch
   - Expect_test_matcher__Cst.to_string
         ppx/ppx_expect/matcher/lexer.mll:108, Unbound value Cst.to_string
   - Expect_test_common__Expectation.Body.map_pretty
         ppx/ppx_expect/matcher/lexer.mll:111, Unbound value Expectation.Body.map_pretty
   - Ppx_assert_lib__Runtime.test_result
         ppx/ppx_expect/matcher/lexer.mll:14, Unbound value Ppx_assert_lib.Runtime.test_result
       This is as-yet unsupported.
       ROTOR doesn't know how to process .mll and .mly files.

   - Expect_test_common__File.Digest.of_string
         ppx/ppx_expect/evaluator/ppx_expect_evaluator.ml:57, Unbound value D.of_string
         ppx/ppx_expect/evaluator/ppx_expect_evaluator.ml:61, Unbound value D.to_string
       This is as-yet unsupported.
       A local module binding is used to create an alias of the parent module
         expect_test_common.File.Digest
       on line
         ppx/ppx_expect/evaluator/ppx_expect_evaluator.ml:39
   - Ppx_inline_test_lib__Runtime.am_running_inline_test_env_var
         lib/core/src/am_running_inline_test.ml:13, Unbound value R.am_running_inline_test_env_var
       This is as-yet unsupported.
       A local module binding is used to create an alias of the parent module
         ppx_inline_test_lib.Runtime
       on line
         lib/core/src/am_running_inline_test.ml:10
   - Expect_test_common__File.Digest.to_string
         ppx/ppx_expect/evaluator/ppx_expect_evaluator.ml:61, Unbound value D.to_string
       There are two issues.
       Firstly, a local module binding is used to create an alias of the parent module
         expect_test_common.File.Digest
       on line
         ppx/ppx_expect/evaluator/ppx_expect_evaluator.ml:39
       However, secondly, the call to the to_string function is somehow
       automatically generated (not sure exactly how yet).
   - Base__Hashtbl.add_exn
         lib/core_kernel/src/hashtbl.ml:133, Unbound value Table.add_exn
       This is as-yet unsupported.
       For the dependency
         core_kernel.Hashtbl#Make:add_exn -> foo
       a local module binding is used to create an alias of an application of 
       the parent module on line
         lib/core_kernel/src/hashtbl.ml:125

   - Core_kernel__Sexp.parse_bigstring
         lib/sexplib/src/pre_sexp.ml:957, Unbound value foo
       This is as-yet unsupported.
       There is some C preprocessing that happens to the file
         lib/sexplib/src/pre_sexp.ml
       which produces the definitions of functions
         parse_string
         parse_bigstring
   - Core_kernel__Sexp.Parse_pos.create
         lib/sexplib/src/pre_sexp.ml;750, Unbound value Parse_pos.create
       This is as-yet unsupported.
       There is a reference to this function embedded within the definition of a
       C-style macro at this location.

   - Base__Hash.[alloc,get_hash_value]
         lib/base/src/hash.ml:106, Unbound value Hash.[alloc,get_hash_value]
       This is a bug:
         The tool is not generating any replacement operations for the dependency
           base.Hash#F[1]:[...] -> foo
         in the file
           lib/base/src/hash.ml
   - Core_kernel__Pool.Unsafe.Slots.slots_per_tuple
   - Core_kernel__Tuple_type.slots_per_tuple
         lib/core_kernel/src/pool.ml:536, Unbound value Slots.slots_per_tuple
   - Core_kernel__Tuple_type.Slots.slots_per_tuple
         lib/core_kernel/src/pool.ml:536, Unbound value Slots.slots_per_tuple
         lib/core_kernel/src/pooled_hashtbl.ml:77, Unbound value Unsafe.Slots.slots_per_tuple
       This is a bug:
         The dependency
           core_kernel.Tuple_type.Slots:slots_per_tuple
         is failing to generate replacements for the locations:
           lib/core_kernel/src/pool.ml:536,27-47
           lib/core_kernel/src/pool.ml:558,10-30
         Also, perhaps this should generate the dependency
           core_kernel.Pool.Slots:slots_per_tuple
         But this would only be visible locally, since the Slots submodule is
         not exposed in the interface of the Pool module.
         In the case of Core_kernel__Tuple_type.Slots.slots_per_tuple, the 
         dependency
           core_kernel.Pool.Unsafe.Slots:slots_per_tuple
         is not even generated, and thus there are no replacements generated for
         the location
           lib/core_kernel/src/pooled_hashtbl.ml:77,27-54
   - Ppx_core__Ast_builder.Default.Located:mk
         ppx/ppx_core/src/ast_builder.ml:248, Unbound value mk
   - Ppx_core__Ast_builder.Default.Located:lident
         ppx/ppx_core/src/ast_builder.ml:249, Unbound value lident
       This is a bug:
         The dependency
           ppx_core.Ast_builder.Default.Located:lident -> foo
         is failing to generate a replacement for the location:
           ppx/ppx_core/src/ast_builder.ml:249,20-25
         which should happen because of the include of the containing module on line
           ppx/ppx_core/src/ast_builder.ml:244
   - Core_kernel__Span.of_sec
         lib/core_kernel/src/span.ml:335, Unbound value of_sec
       This is a bug:
         The dependency
           core_kernel.Span.Stable.V1:of_sec -> foo
         is failing to generate a replacement for the location:
           lib/core_kernel/src/span.ml:335,20-25
         which should happen because of the include of the containing module on line
           lib/core_kernel/src/span.ml:330
   - Core_kernel__Time_float.of_date_ofday
         lib/core/src/core_time.ml:327, Unbound value Time.of_date_ofday
       This is a bug:
         The dependency
           core_kernel.Time_intf%S:of_date_ofday
         is failing to generate a replacement for the location
           lib/core/src/core_time.ml:327,33-51
         The log shows a log of "Bad locations" errors
   - Core__Core_time_float.Zone.likely_machine_zones
         lib/core/src/core_time.ml:159, Unbound value Time.Zone.likely_machine_zones
       This is a bug:
         The dependency
           core.Core_time#Make[2].Zone:likely_machine_zones -> foo
         is failing to generate a replacement for the location
           lib/core/src/core_time.ml:159,19-49
         
   - Base__Hashtbl.Poly.create
   - Core_kernel__Int.Table.create
   - Core_kernel__String.Table.create
         lib/base/src/hash_set.ml:114, Unbound value Hashtbl.create
       This is a bug:
         The dependency
           base.Hashtbl_intf%Creators:create
         should generate (among others) the dependency
           base.Hashtbl_intf%S_using_hashable:create
         due to the signature include on line
           lib/base/src/hashtbl_intf.ml:396
         which should, in turn, generate the dependency
           base.Hashtbl_intf%Hashtbl.Using_hashable:create
         due to the module type annotation on line
           lib/base/src/hashtbl_intf.ml:439
         For some reason, this is not happening.
   - Core__Iobuf.Blit.blit
         lib/core_kernel/src/pool.ml:521, Unbound value Obj_array.blit
   - Core__Bigstring.From_string.unsafe_blit
   - Core__Bigstring.To_string.unsafe_blit
   - Core__Bigstring.unsafe_blit
   - Core_kernel__Bigstring.To_string.unsafe_blit
   - Core_kernel__Uniform_array.unsafe_blit
         lib/core_kernel/src/uniform_array.ml:35, Unbound value Obj_array.unsafe_blit
       This is a bug:
         One of the dependencies
           base.Blit%S:blit -> foo
           base.Blit_intf%S:blit -> foo
         should generate the dependency
           core_kernel.Obj_array:blit -> foo
         due to the signature include on line
           lib/core_kernel/src/obj_array.mli:20
   - Core_kernel__Obj_array.unsafe_blit
         lib/core_kernel/src/option_array.ml:199, Unbound value Uniform_array.unsafe_blit
       This is a bug
         The dependency
           base.Blit_intf%Blit%S1:unsafe_blit -> foo
         should generate the dependency
           core_kernel.Blit_intf%Blit%S1:unsafe_blit
         due to this signature include on line
           lib/core_kernel/src/blit_intf.ml:26

   - Core_kernel__Float.is_positive
         lib/base/src/int63.ml:23, Unbound value is_positive
       This is as-yet unsupported.
       There are a number of issues.
       - Firstly, the dependency
           base.Int63_backends%Int_or_more:is_positive -> foo
         should generate the dependency
           base.Int63_backends.Dynamic:is_positive -> foo
         However this comes from base.Int63_backends.Dynamic being declared as
         an alias of a first class module on line
           lib/base/src/int63_backends.ml:35
       - Secondly, the file
           lib/base/src/int63_backendml
         is generated automatically, and is a simple include of
           base.Int63_backends.Dynamic
         Thus, we have the dependency
           base.Int63_backend:is_positive -> foo
         which should then lead to the dependency
           base.int63:is_positive -> foo
         due to the module include on line
           lib/base/src/int63.ml:6

   - Base__Int.hash
   - Core_kernel__Int.hash
         lib/base/src/hashtbl_intf.ml:34, Unbound value Key.hash
       This is as-yet unsupported
         The signature base.Hashtbl_intf%Key is used as the interface to a
         first-class module function parameter on line:
           lib/base/src/hashtbl_intf.ml:33
   - Core_kernel__Float.zero
   - Core_kernel__Span.zero
         lib/base/src/container.ml:18, Unbound value M.zero
       This is as-yet unsupported
         The signature base.Commutative_group%S is used as the interface to a
         first-class module function parameter on line:
           lib/base/src/container.ml:17

