Skip to content

Projecting to an associated constant fails but with wrong reason #61815

New issue

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

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

Already on GitHub? # to your account

Open
Centril opened this issue Jun 13, 2019 · 2 comments
Open

Projecting to an associated constant fails but with wrong reason #61815

Centril opened this issue Jun 13, 2019 · 2 comments
Labels
A-associated-items Area: Associated items (types, constants & functions) A-lazy-normalization Area: Lazy normalization (tracking issue: #60471) A-type-system Area: Type system C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Jun 13, 2019

When you have:

trait Tr {
    const C: usize = 0;
    fn fun(x: [u8; Self::C]) -> [u8; 0] { x }
}

you get the usual problem:

error[E0599]: no associated item named `C` found for type `Self` in the current scope
 --> src/lib.rs:3:26
  |
3 |     fn fun(x: [u8; Self::C]) -> [u8; 0] { x }
  |                          ^ associated item not found in `Self`
  |
  = help: items from traits can only be used if the trait is implemented and in scope
  = note: the following trait defines an item `C`, perhaps you need to implement it:
          candidate #1: `Tr`

That this errors is right. However, it fails for the wrong reason.

What should happen here is that Self::C is seen as an opaque constant the value of which you don't get to assume in fun's body. Therefore you should get a type error:


error[E0308]: mismatched types
 --> src/lib.rs:L:C
  |
L |     fn fun(x: [u8; Self::C]) -> [u8; 0] { x }
  |                                           ^ expected [u8; 0], found [u8; Self::C]
  |
  = note: expected type `[u8; 0]`
             found type `[u8; Self::C]`

cc #61812
cc #29661

@Centril Centril added A-type-system Area: Type system A-associated-items Area: Associated items (types, constants & functions) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. A-lazy-normalization Area: Lazy normalization (tracking issue: #60471) labels Jun 13, 2019
@jonas-schievink
Copy link
Contributor

I think this is just #43408?

Since #![feature(const_generics)] does make generics available in that context, enabling it results in the correct error:

#![feature(const_generics)]

trait Tr {
    const C: usize = 0;
    fn fun(x: [u8; Self::C]) -> [u8; 0] { x }
}
error[E0308]: mismatched types
 --> src/lib.rs:5:43
  |
5 |     fn fun(x: [u8; Self::C]) -> [u8; 0] { x }
  |                                 -------   ^ expected `0usize`, found `Self::C`
  |                                 |
  |                                 expected `[u8; 0]` because of return type
  |
  = note: expected array `[u8; 0]`
             found array `[u8; _]`

@jonas-schievink jonas-schievink added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Jan 5, 2020
@mcy
Copy link
Contributor

mcy commented Feb 6, 2020

This seems to be different, because I ran into the same diagnostic with code that, as far as I can tell, is actually correct:

trait T {
    const N: usize;
    fn fun(x: [u8; Self::N]);
}

(i.e., the compiler suggests constraining Self: T).

When I turn on const generics, I get

error: constant expression depends on a generic parameter
 --> src/lib.rs:5:15
  |
5 |     fn fun(x: [u8; Self::N]);
  |               ^^^^^^^^^^^^^
  |
  = note: this may fail depending on what value the parameter takes

which I assume is just some array-specific failsafe, since this all works fine when I use pub struct Ignore<const N: usize>; instead.

@fmease fmease added the T-types Relevant to the types team, which will review and decide on the PR/issue. label Dec 21, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-associated-items Area: Associated items (types, constants & functions) A-lazy-normalization Area: Lazy normalization (tracking issue: #60471) A-type-system Area: Type system C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants