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

matching against an associated constant gives type error #57280

Closed
nikomatsakis opened this issue Jan 2, 2019 · 1 comment · Fixed by #57304
Closed

matching against an associated constant gives type error #57280

nikomatsakis opened this issue Jan 2, 2019 · 1 comment · Fixed by #57304
Assignees
Labels
A-NLL Area: Non Lexical Lifetimes (NLL) P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@nikomatsakis
Copy link
Contributor

Ever since #55937, the following program (playground) gives an unexpected error from NLL:

#![feature(nll)]

trait Foo {
    const Blah: &'static str;
}

struct Placeholder;

impl Foo for Placeholder {
    const Blah: &'static str = "hi";
}

fn foo(x: &str) {
    match x {
        <Placeholder as Foo>::Blah => { }
        _ => { }
    }
}

First reported by @Xanewok in this comment, because this broke the RLS.

cc @davidtwco

@nikomatsakis nikomatsakis added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. P-high High priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-NLL Area: Non Lexical Lifetimes (NLL) labels Jan 2, 2019
@nikomatsakis nikomatsakis self-assigned this Jan 2, 2019
Xanewok added a commit to Xanewok/rust that referenced this issue Jan 2, 2019
Breakage was due to rust-lang#55937,
which seemed to introduce a regression (tracked over at
rust-lang#57280).
@nikomatsakis
Copy link
Contributor Author

I dug into this a bit -- see the [zulip log] for full details. In short, the problem is:

  • In 4be7214, we added a check that the type T of the value being matched must be a subtype of the type C of the constant
  • The lexical type checker has the reverse: C <: T (link)
  • Really neither is quite right, but we can match the lexical type checker by including a notion of "variance" on the pattern type annotations

Probably what we really want is to require that T: PartialEq<C>.

@davidtwco davidtwco self-assigned this Jan 3, 2019
bors added a commit that referenced this issue Jan 7, 2019
NLL: Fix bug in associated constant type annotations.

Fixes #57280.

This PR reverses the variance used when relating types from the type
annotation of an associated constant - this matches the behaviour of the
lexical borrow checker and fixes a bug whereby matching a `&'a str`
against a `&'static str` would produce an error.

r? @nikomatsakis
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-NLL Area: Non Lexical Lifetimes (NLL) P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants