Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007134OCamltypingpublic2016-02-03 20:012017-03-14 11:22
Assigned Togarrigue 
PrioritynormalSeverityfeatureReproducibilityhave not tried
PlatformOSOS Version
Product Version4.02.3 
Target VersionundecidedFixed in Version 
Summary0007134: compiler forcing aliases it shouldn't while reporting type errors
DescriptionThis is a similar problem to 0006812, the compiler reads cmis it shouldn't, resulting in inconsistent assumptions. But if the cmi doesn't exist, the compiler doesn't read it and so succeeds (at giving a type error).

Stack trace at the moment when the wrong cmi is read (lib__C.cmi in the example below):
#0 0x000000000050c4b0 in camlEnv__read_pers_struct_1510 ()
#1 0x000000000050d22f in camlEnv__find_module_1610 ()
#2 0x00000000005102a0 in camlEnv__scrape_alias_2090 ()
0000003 0x0000000000511ea7 in camlEnv__components_of_module_maker_2201 ()
0000004 0x000000000050ba2c in camlEnv__force_1253 ()
0000005 0x000000000050fccc in camlEnv__find_all_comps_2002 ()
0000006 0x0000000000602df1 in camlList__map_1040 () at
0000007 0x0000000000602e08 in camlList__map_1040 () at
0000008 0x000000000050ff1a in camlEnv__find_shadowed_2019 ()
0000009 0x000000000050ff5d in camlEnv__find_shadowed_types_2029 ()
0000010 0x0000000000540742 in camlPrinttyp__is_unambiguous_1550 ()
0000011 0x000000000053cdb3 in camlPrinttyp__fun_3062 ()
0000012 0x0000000000602f81 in camlList__iter_1061 () at
0000013 0x00000000005409c3 in camlPrinttyp__get_best_path_1562 ()
0000014 0x0000000000540ada in camlPrinttyp__best_type_path_1568 ()
0000015 0x000000000053d248 in camlPrinttyp__pr_typ_1679 ()
0000016 0x000000000053c49b in camlPrinttyp__pr_arrow_1697 ()
0000017 0x0000000000543379 in camlPrinttyp__tree_of_value_description_1908 ()
0000018 0x0000000000558341 in camlIncludemod__fun_1891 ()
0000019 0x000000000062e797 in camlFormat__output_acc_1501 () at
0000020 0x000000000062ea5c in camlFormat__output_acc_1501 () at
0000021 0x000000000062e797 in camlFormat__output_acc_1501 () at
0000022 0x000000000062e97f in camlFormat__output_acc_1501 () at
0000023 0x000000000062e797 in camlFormat__output_acc_1501 () at
0000024 0x000000000062b710 in camlFormat__fun_2372 () at
0000025 0x000000000055ad61 in camlIncludemod__include_err_1460 ()
0000026 0x000000000062e797 in camlFormat__output_acc_1501 () at
#27 0x000000000062b710 in camlFormat__fun_2372 () at
0000028 0x00000000004a59c4 in camlMisc__try_finally_1011 ()
0000029 0x000000000062e797 in camlFormat__output_acc_1501 () at
#30 0x000000000062b710 in camlFormat__fun_2372 () at
#31 0x00000000004ae0dc in camlLocation__error_of_printer_1190 ()
0000032 0x000000000055ba39 in camlIncludemod__fun_2018 ()
0000033 0x00000000004ac982 in camlLocation__loop_1167 ()
0000034 0x00000000004ae2ea in camlLocation__report_exception_rec_1202 ()
0000035 0x000000000044b825 in camlOptmain__main_1484 ()
0000036 0x000000000044cdf4 in camlOptmain__entry ()
0000037 0x0000000000447249 in caml_program ()
0000038 0x00000000006497d6 in caml_start_program ()
Steps To Reproduce#!/bin/bash

rm -rf /tmp/inconsistent-assumptions
mkdir -p /tmp/inconsistent-assumptions
cd /tmp/inconsistent-assumptions

cat > <<EOF
type t

cat > <<EOF
module C = struct
  type t = { a : A.t }
  let f t = t.a

include C

cat > b.mli <<EOF
val f : string

touch lib__C.cmi # let's pretend we have a version of
                 # that was built against a different a.cmi

cat > <<EOF
module A = Lib__A
module B = Lib__A
module C = Lib__C

$ocaml -nostdlib -nopervasives -no-alias-deps -w +a-49 -short-paths -o lib.cmx -c
$ocaml -nostdlib -nopervasives -no-alias-deps -w +a -short-paths -open Lib -o lib__A.cmx -c
$ocaml -nostdlib -nopervasives -no-alias-deps -w +a -short-paths -open Lib -o lib__B.cmi -c b.mli
$ocaml -nostdlib -nopervasives -no-alias-deps -w +a -short-paths -open Lib -o lib__B.cmx -c
# -nostdlib and -nopervasives are not necessary, they just reduce irrelevant noise

# results in:
# File "", line 1:
# Error: Corrupted compiled interface
# lib__C.cmi
# instead of a proper type error
TagsNo tags attached.
Attached Files

- Relationships
related to 0006812closedgarrigue Combination of -short-paths and -no-alias-deps can create inconsistent assumptions 

-  Notes
garrigue (manager)
2016-02-25 08:56

I'm not sure what to do here.
This is not a bug of the compiler: as always, it returns the first error it found, and having a wrong cmi in your path is indeed an error.
Your point seems to be that since not having a cmi is actually legal, we should not fail in that case, just ignore the broken file. But wouldn't it be even more confusing, if you were actually expecting a cmi for that file?
To me this looks more like a hygiene problem than a compiler feature.
garrigue (manager)
2016-02-25 09:00

Oh, wait a minute. Does the problem only occur with -short-paths?
In that case it might be related to the way -short-paths explores its environment before reporting errors. The code was written before the introduction of module aliases, and there may be bad interactions.
sliquister (reporter)
2016-02-25 14:57

Yeah, I think it's only with short-paths and -no-alias-deps, otherwise modules can't even alias modules they don't depend on.
sliquister (reporter)
2016-07-29 21:03

This bites people occasionally. Instead of finding every place in the typer that might be forcing aliases to compilation units that the input program doesn't use, how about:
- adding 'val Env.can_load_cmis : bool ref = ref false'
- using it in Env.find_pers_struct to refuse to load cmis
- setting it to true around the part of the typer where it does error reporting

This assumes the typer doesn't have legitimate reasons to load compilation units that weren't loaded at the time the type error was found. Not sure if this is true.
sliquister (reporter)
2016-07-29 21:05

Oops, I meant the ref defaults to true and would be set to false for error reporting.
sliquister (reporter)
2016-08-01 18:31
edited on: 2016-08-01 18:33

Alternatively, I think (haven't tested) that something like [^] would allow to change the way we build to not produce these forward references anymore.
And without forward references, this problem (and at least one other I have reported and was fixed) go away.

The idea would be that instead of creating, for each library, a module aliasing all the modules of the library, and make every module of the library open the aliases module, I would have a preprocessor that would create just the aliases a given module needs.
In the example above, would contain (after preprocessing):
open struct module A = Lib__A end (* from preprocessor *)
module C = struct
  type t = { a : A.t }
  let f t = t.a
and so the compiler would have no reason to look for lib__C.cmi.

(and this would also require a similar feature in signatures: open sig .. end)

garrigue (manager)
2016-08-03 06:08 [^] makes sense to me.
The compiler indeed has no good reason to load cmis when reporting error: if it found an error, it has already loaded all the relevant cmis that are involved in the error.
I'll see if it can be done cleanly.

Your workaround might work, but we don't want to force all users to use such an approach.
garrigue (manager)
2016-08-03 06:14

By the way, Frédéric Bour was supposed to change the way -short-paths works.
He has a cleaner approach, which exploits nicely module aliases.
Still waiting for it.
garrigue (manager)
2016-08-22 04:47

Tentative fix using sliquister's idea at [^]

Could you quickly tell me if this solves all your problems?
sliquister (reporter)
2016-08-23 19:07

The tip of the feature is broken because the second commit sets the boolean to true instead of false, effectively doing nothing.
But other than that:
- the test in the description passes
- the problem that made me ping this PR in July gives a type error rather than inconsistent assumptions (when I backport the patch, I can't use a new compiler version)

I haven't tested the problem that made me create this PR, I'm going to try now if it's not too hard.
sliquister (reporter)
2016-08-23 20:22

I reproduced the bug from February, and this one also gives a type error instead of inconsistent assumptions with this change.

I wonder if the fix from 0006812 is still necessary, with this.
sliquister (reporter)
2016-08-23 21:02

I checked the reproduction from 0006812 with 4.02.1 (inconsistent assumptions) and 4.02.1 + this patch (the expected type error).
garrigue (manager)
2016-08-23 22:41

Fixed in 4.04 by GPR 0000774.

Should add a test case, and check whether the fix of 6812 is really needed now.
(It does something different, but is it semantically useful?)

- Issue History
Date Modified Username Field Change
2016-02-03 20:01 sliquister New Issue
2016-02-08 12:21 doligez Status new => acknowledged
2016-02-08 12:21 doligez Target Version => 4.03.0+dev / +beta1
2016-02-25 08:56 garrigue Note Added: 0015394
2016-02-25 08:56 garrigue Assigned To => garrigue
2016-02-25 08:56 garrigue Status acknowledged => feedback
2016-02-25 09:00 garrigue Note Added: 0015395
2016-02-25 14:57 sliquister Note Added: 0015398
2016-02-25 14:57 sliquister Status feedback => assigned
2016-04-14 17:51 doligez Target Version 4.03.0+dev / +beta1 => 4.03.1+dev
2016-07-29 21:03 sliquister Note Added: 0016151
2016-07-29 21:05 sliquister Note Added: 0016152
2016-08-01 18:31 sliquister Note Added: 0016162
2016-08-01 18:32 sliquister Note Edited: 0016162 View Revisions
2016-08-01 18:33 sliquister Note Edited: 0016162 View Revisions
2016-08-03 06:08 garrigue Note Added: 0016176
2016-08-03 06:14 garrigue Note Added: 0016177
2016-08-22 04:47 garrigue Note Added: 0016220
2016-08-22 04:47 garrigue Status assigned => feedback
2016-08-23 19:07 sliquister Note Added: 0016234
2016-08-23 19:07 sliquister Status feedback => assigned
2016-08-23 20:22 sliquister Note Added: 0016235
2016-08-23 21:02 sliquister Note Added: 0016236
2016-08-23 22:40 garrigue Relationship added related to 0006812
2016-08-23 22:41 garrigue Note Added: 0016237
2017-02-16 14:00 doligez Target Version 4.03.1+dev => undecided
2017-02-23 16:45 doligez Category OCaml typing => typing
2017-03-14 11:22 garrigue Severity minor => feature

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker