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

Types not inferred properly for fields on record overrides #6303

Closed
vicuna opened this issue Jan 22, 2014 · 2 comments
Closed

Types not inferred properly for fields on record overrides #6303

vicuna opened this issue Jan 22, 2014 · 2 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Jan 22, 2014

Original bug ID: 6303
Reporter: @alainfrisch
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2015-12-11T18:25:37Z)
Resolution: fixed
Priority: normal
Severity: major
Fixed in version: 4.02.0+dev
Category: typing
Monitored by: @gasche @jmeber @hcarty

Bug description

On trunk, it seems that an expression {e with x = ...} does not propagate type constraints from x to the record type. The following code segfaults:

type 'a foo = {x: 'a; y: int}
let r = {{x = 0; y = 0} with x = 0}
let () = print_endline (r.x ^ "")

The type inferred for [r] is a polymorphic ['a foo], instead of [int foo].

@vicuna
Copy link
Author

vicuna commented Jan 22, 2014

Comment author: @alainfrisch

Introduced by commit 14166, and more precisely this change:

            let op =
              match opt_exp with
                None -> None
              | Some exp -> get_path exp.exp_type
            in
            newvar (), op

---->

            begin match opt_exp with
              None -> newvar (), None
            | Some exp ->
                match get_path exp.exp_type with
                  None -> newvar (), None
                | Some (_, p', _) as op ->
                    let decl = Env.find_type p' env in
                    begin_def ();
                    let ty =
                      newconstr p' (instance_list env decl.type_params) in
                    end_def ();
                    generalize ty;
                    ty, op
            end

Removing the call to [generalize] seems to solve the issue. Jacques: is it a correct fix?

@vicuna
Copy link
Author

vicuna commented Jan 23, 2014

Comment author: @garrigue

Fixed in revision 14415.
In this case we should only generalize the structure: use generalize_structure rather than generalize.

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

No branches or pull requests

2 participants