Skip to content

Associated constants inside array repeat expression don't use implied bounds from impl header during well-formedness checking #89236

Description

@typesanitizer

I tried this code: (try it in a playground)

use std::hash::BuildHasher;
use std::collections::HashMap;

trait H: Send + Sync + Clone + BuildHasher { }

struct I<'i, RS: H> {
    h: &'i HashMap<i32, i32, RS>,
    s: VeryVeryLongTypeName
}
impl<'i, RS: H> I<'i, RS> {
    const CHUNK_SIZE: usize = VeryVeryLongTypeName::CHUNK_SIZE;
    fn go(&mut self) {
        self.s.chunks.push(Box::new([0; Self::CHUNK_SIZE])); // ERROR
    }
}

struct VeryVeryLongTypeName {
    chunks: Vec<Box<[u8; Self::CHUNK_SIZE]>>
}
impl VeryVeryLongTypeName {
    const CHUNK_SIZE: usize = 69;
}

I expect this code to either compile fine or provide a warning similar to #76200.

However, I see an error:

11 | impl<'i, RS: H> I<'i, RS> {
   |          --- help: consider adding an explicit lifetime bound...: `RS: 'i +`
...
15 |         self.s.chunks.push(Box::new([0; Self::CHUNK_SIZE]));
   |                                         ^^^^ ...so that the type `RS` will meet its required lifetime bounds

I don't understand why RS: 'i is needed for accessing a constant off of Self. As one might expect, replacing Self::CHUNK_SIZE with VeryVeryLongTypeName::CHUNK_SIZE works around the issue.

Tested with stable 1.55.0 and 1.57.0-nightly (2021-09-23 2b862bed9889808b6962).

Activity

  1. changed the title [-]Confusing diagnostic when mixing generics, lifetimes and associated consts[/-] [+]Incorrect diagnostic when mixing generics, lifetimes and associated consts[/+] on Sep 24, 2021
  2. added
    T-typesRelevant to the types team, which will review and decide on the PR/issue.
    A-implied-boundsArea: Implied bounds / inferred outlives-bounds
    and removed on Jan 24, 2024
  3. fmease commented on Jan 24, 2024

    @fmease
    Member

    Hmm, I expected #120019 to fix this similar to #83014 but apparently it didn't. I need to think a bit if your code works as intended or not.

  4. fmease commented on Dec 29, 2024

    @fmease
    Member

    Revisiting this, I think this is a duplicate of #105495. For struct I and subsequently {impl#0} we have the implied bound RS: 'i but it's not used when trying to check I::go for well-formedness.

  5. reopened this on Dec 29, 2024
  6. fmease commented on Dec 29, 2024

    @fmease
    Member

    Actually I'm not sure if it's a duplicate of that issue. This probably a separate issue.

  7. fmease commented on Dec 29, 2024

    @fmease
    Member

    So, interestingly the following code compiles successfully:

    struct S<'a, T>(&'a T);
    
    impl<'a, T> S<'a, T> {
        const K: usize = 0;
        fn f() { let _ = Self::K; }
    }

    However, once you place the Self::K into the array repeat expr, it fails:

    struct S<'a, T>(&'a T);
    
    impl<'a, T> S<'a, T> {
        const K: usize = 0;
        fn f() { let _ = [(); Self::K]; } //~ ERROR type parameter `T` may not live long enough
    }
  8. added
    S-has-mcveStatus: A Minimal Complete and Verifiable Example has been found for this issue
    on Dec 29, 2024
  9. changed the title [-]Incorrect diagnostic when mixing generics, lifetimes and associated consts[/-] [+]Associated constants inside array repeat expression don't use implied bounds from impl header during well-formedness checking[/+] on Dec 29, 2024
  10. fmease commented on Dec 29, 2024

    @fmease
    Member

    Note: I wrote "well-formedness checking" but haven't actually double-checked if this is true or if this obligation failure stems from some other system in the compiler.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-associated-itemsArea: Associated items (types, constants & functions)A-implied-boundsArea: Implied bounds / inferred outlives-boundsA-trait-systemArea: Trait systemC-bugCategory: This is a bug.S-has-mcveStatus: A Minimal Complete and Verifiable Example has been found for this issueT-typesRelevant to the types team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions