Using const fn constructor instead of struct expression with large number of constants causes compilation to fail because of large memory allocation.

[CDirkx]

I have:

• A struct CodePoint with a const fn from(...) -> Self constructor
• A large number of CodePoint constants (42.000+) using the constructor

#[repr(transparent)]
pub struct CodePoint {
    raw: u32
}

impl CodePoint {
    pub const fn from(raw: u32) -> Self {
        // debug_assert!(raw <= 0x10FFFF);
        CodePoint { raw }
    }
}

// include!(...)
// 42508 constants, 3.28MB file
impl CodePoint {
    pub const SPACE : CodePoint = CodePoint::from(32u32);
    ...
}

Building this leads to:

• Compiler busy for 2min+
• Compiler error trying to allocate 1.2GB:
  memory allocation of 1207959552 bytes failed
  even though I have 12GB of unused RAM

Using struct expressions instead of a const fn constructor:

impl CodePoint {
    pub const SPACE : CodePoint = CodePoint { raw: 32u32 };
    ...
}

• Compiler finishes within 5s.

Tested on nightly and stable, with include!(...) and copy-pasting: no differences.

Source file to reproduce: reproduce.zip

[CDirkx]

I know 42.000+ constants is probably not the best idea, but with the struct expression case finishing within 5s I would expect the compiler to be able to handle them, as the const constructor does exactly the same thing.

[ecstatic-morse]

The hot code here is rustc_typeck::check::method::<impl rustc_typeck::check::FnCtxt>::associated_item (80% CPU), which does a linear scan to find an associated item with a particular name. Seems like each associated const needs to do method lookup to find the constructor, which then needs to scan over all other associated consts before it finds CodePoint::from.

[ecstatic-morse]

@rustbot claim

[ecstatic-morse]

@CDirkx compile time has improved a lot in the current nightly. const_constructor now takes ~30s with a local, non-LTO master build compared to ~15s for struct_literal. #69072 will improve this further: const_constructor takes about the same amount of time as struct_literal with that PR applied.

[CDirkx]

Yes I can confirm that on the current nightly memory usage by rustc is way lower (not claiming multiple GBs of RAM anymore), resulting in not running out of memory anymore and succesfull compilation at the speeds you mention.

I also tried with all named Unicode code points included (including names like CJK_UNIFIED_IDEOGRAPH_2D6CE, 135.000+ total; reproduce_all.zip), this also compiled just fine while taking around 1.5 mins, which will be improved by your PR.

Thanks for taking the time to make Rust work with this admittedly non-standard code.