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

bare fn types in record unification produces unexpected errors #1451

Closed
nikomatsakis opened this issue Jan 7, 2012 · 3 comments
Closed

bare fn types in record unification produces unexpected errors #1451

nikomatsakis opened this issue Jan 7, 2012 · 3 comments
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-type-system Area: Type system
Milestone

Comments

@nikomatsakis
Copy link
Contributor

In the following source:

type T = { mutable f: fn@() };
type S = { f: fn@() };

fn fooS(t: S) {
}

fn fooT(t: T) {
}

fn bar() {
}

fn main() {
    let x: fn@() = bar;
    fooS({f: x});
    fooS({f: bar});

    let x: fn@() = bar;
    fooT({mutable f: x});
    fooT({mutable f: bar});
}

the last call to fooT() results in an error:

/Users/nmatsakis/tmp/foo.rs:20:9: 20:25 error: mismatched types: expected `T` but found `{f: mutable fn()}` (types differ)
/Users/nmatsakis/tmp/foo.rs:20     fooT({mutable f: bar});

I believe this is because the field f is immutable and hence unified as invariant. This is kind of surprising to the user, though. The "right" fix is probably a bit involved though. If we were to get rid of bare function types, we'd be able to handle this, but it requires an improvement to the type checker (bounded type variables, since you don't know the type to assign to the bare function till later).

@catamorphism
Copy link
Contributor

Updating this to use "mut" instead of "mutable", I get:

./src/test/run-pass/issue-1451.rs:20:9: 20:21 error: mismatched types: expected `T` but found `{f: mut native fn()}` (in field `f`, closure protocol mismatch (native fn vs fn@))
./src/test/run-pass/issue-1451.rs:20     fooT({mut f: bar});

This is basically the same error, but the "closure protocol mismatch" part is new and is, perhaps, more helpful? @nikomatsakis , should this be closed?

@ghost ghost assigned nikomatsakis Apr 12, 2012
@catamorphism
Copy link
Contributor

Now the error message is:

issue-1451.rs:20:9: 20:22 error: mismatched types: expected `T` but found `{f: mut fn()}` (in field `f`, expected @ closure, found  closure)
issue-1451.rs:20     fooT({mut f: bar});

Still could be improved.

@catamorphism
Copy link
Contributor

No more structural records mean this is a non-issue now, I think.

fhahn added a commit to fhahn/rust that referenced this issue Feb 22, 2014
* compile-fail/vec-add.rs is obsolete, there are no mutable
  vectors any more, rust-lang#2711 is closed
* compile-fail/issue-1451.rs is obsolete, there are no more
  structural records, rust-lang#1451 is closed
* compile-fail/issue-2074.rs is obsolete, an up to date test
  is in run-pass/nested-enum-same-names.rs, rust-lang#2074 is closed
* compile-fail/omitted-arg-wrong-types.rs is obsolete, rust-lang#2093
  is closed
alexcrichton pushed a commit to alexcrichton/rust that referenced this issue Feb 25, 2014
* compile-fail/vec-add.rs is obsolete, there are no mutable
  vectors any more, rust-lang#2711 is closed
* compile-fail/issue-1451.rs is obsolete, there are no more
  structural records, rust-lang#1451 is closed
* compile-fail/issue-2074.rs is obsolete, an up to date test
  is in run-pass/nested-enum-same-names.rs, rust-lang#2074 is closed
* compile-fail/omitted-arg-wrong-types.rs is obsolete, rust-lang#2093
  is closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

2 participants