`#![feature(const_fn)]` causes rustdoc to drop the `const` keyword when documenting instances of `const fn`

[slightlyoutofphase]

This is a follow-up on the now-closed issue I opened earlier, with the requested minimal reproduction in the form of a simple lib.rs.

// If the feature flag below is commented out, the code is documented correctly.
// With it enabled, the two `pub const fn`s are documented as just `pub fn`.
#![feature(const_fn)]

/// A useless function that always returns 1.
pub const fn bloop() -> i32 {
    1
}

/// A struct.
pub struct Struct {}

impl Struct {
    /// A useless function that always returns 1.
    pub const fn bloop() -> i32 {
        1
    }
}

[jyn514]

Looks like this is either

rust/src/librustdoc/clean/mod.rs

Line 903 in 085e417

let constness = if is_min_const_fn(cx.tcx, did.to_def_id()) {

or

rust/src/librustdoc/clean/mod.rs

Lines 1156 to 1160 in 085e417

	if m.header.constness == hir::Constness::Const
	&& !is_min_const_fn(cx.tcx, local_did.to_def_id())
	{
	m.header.constness = hir::Constness::NotConst;
	}

cc @GuillaumeGomez - do you know what those are doing/why they exist?

[GuillaumeGomez]

It's because of the feature. As long as it's not stable, they don't want the const keyword to be displayed, even if the function description is describing a const fn. This is a bit strange.

[slightlyoutofphase]

Yeah, that makes no sense to me at all. I have a crate that is very much nightly-only containing a rather large number of const fns, and at the moment literally none of them are displayed as such in my documentation because of this, despite the fact that they've never not been const fn and will never not be const fn in the future.

I of course cannot disable the flag either as then the crate won't compile, as much of what I'm doing does not fit into the stabilized min_const_fn set of functionality.

At the very least, surely there must be some way to make it possible to specifically tell rustdoc to "please always document const fns as exactly what they are no matter what" without changing this default behaviour if that's not desired?

[jyn514]

@GuillaumeGomez I think the metric should be 'does this have rustc_const_unstable, not 'is this a min_const_generics function'.

[GuillaumeGomez]

I wonder if this isn't an artifact of the switch when adding const support... But in any case, it should be a check over rustc_const_unstable, you're absolutely right.

[jyn514]

I wonder if this ever worked ... @slightlyoutofphase do you mind trying this with an old version of rustdoc? Preferably before min_const_generics was implemented: #74877.

cc @lcnr

[slightlyoutofphase]

@jyn514 I'll try that on my crate later today.

[slightlyoutofphase]

After testing both the example I gave here and my own crate with various nightlies from before min_const_generics was implemented, I can confirm that this problem definitely pre-dates it. There's no difference in how rustdoc behaved.

[jyn514]

(apologies to lcnr for the ping)

[slightlyoutofphase]

If this helps at all, whichever version of rustdoc docs.rs was using on August 1st did document my crate properly, it seems. Only the very latest version, uploaded on September 5th, was documented with the const keyword missing. So it's a fairly recent bug, overall.