Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cross-module-inlining behaves inconsistently and differently than friending #3188

Open
gebner opened this issue Jan 10, 2024 · 0 comments
Open

Comments

@gebner
Copy link
Contributor

gebner commented Jan 10, 2024

Consider the following four files:

// A.fsti
module A
val t: Type0
val s0: Type0
// We wrap the type in a match to trigger automatic coercion.
inline_for_extraction let s1 b = if b then t else s0
inline_for_extraction let s = s1 false
val t_eq_s: squash (t==s)

// A.fst
module A
let t = nat
let s0 = nat
let t_eq_s = ()

// B.fsti
module B

// B.fst
module B
open A
let f (x:t) : s = x

Extracting ocaml code from B.fst results in this function, expectedly using magic:

let (f : A.t -> A.s0) = fun uu___ -> (fun x -> Obj.magic x) uu___

If we add friend A to B.fst, then extraction can (again, as expected) see through the type definitions:

let (f : A.t -> A.s0) = fun x -> x

However, --cmi uses magic (while it should probably behave as if everything was in the same file). Even more surprisingly, if you tag either t or s0 as inline_for_extraction, then extraction with --cmi sees through the other definition as well (even though they are not defined in terms of each other):

let (f : Prims.nat -> A.s0) = fun x -> x

This is potentially related to the extraction failure in project-everest/mitls-fstar#260

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant