Don't rely on promotion of PageTableEntry::new inside a const fn

[ecstatic-morse]

Hi! Rust compiler team member here. When the const_fn feature is enabled, the implementation of PageTable::new relies on a compiler bug to work. Specifically, PageTableEntry::new should not be eligible for promotion as part of an array initializer. See rust-lang/rust#75502 for more information. This bug may be fixed in the future, which would cause this crate to stop compiling.

[phil-opp]

Thanks a lot for the early warning and for taking the time to fix this for us!

I'm wondering if the following would work too:

    pub const fn new() -> Self {
        const EMPTY: PageTableEntry = PageTableEntry::new();
        PageTable {
            entries: [EMPTY; ENTRY_COUNT],
        }
    }

Here we initialize the array with a const, which should be ok, right? And assigning the result of a const fn to a const should be ok as well, or am I missing something?

The advantage of this implementation would be that it doesn't need access to the private entry field of the PageTableEntry struct, which seems a bit cleaner to me. (I'm happy to implement this change myself, I just wanted to ensure that isn't buggy too.)

[ecstatic-morse]

That works too! The problems that can result from promoting calls to const fn are described in more detail in rust-lang/const-eval#19. In this particular case, promotion of a panicking const fn would actually be fine, since if an array initializer of a non-Copy type cannot be promoted, compilation will fail regardless. However, we're not yet willing to commit to these semantics for the unstable const_in_array_repeat_expressions feature, hence the (possible) breakage.

[phil-opp]

Thanks a lot for the explanation!

[phil-opp]

Published as v0.11.5.