#![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.

[slightlyoutofphase]

Ok, so I think I was reading the dates on the PRs a bit wrong when I tested yesterday as far as the timeframe for when min_const_fn was merged.

I just did a whole bunch more one-by-one testing of nightlies from August, and in fact the problem doesn't quite predate min_const_fn which was merged on August 7th.

Specifically, the very last nightly to have a rustdoc that documents const fn correctly is nightly-2020-08-10. Switching directly from that to nightly-2020-08-11 from the next day makes the problem appear.

[jyn514]

@slightlyoutofphase consider using https://github.com/rust-lang/cargo-bisect-rustc/blob/master/TUTORIAL.md instead which will do it automatically

[slightlyoutofphase]

Well, I already know it's a commit from between the 10th and 11th of August now, at least. Also, cargo-bisect-rustc doesn't really seem to be designed for scenarios where identifying the problem specifically requires running cargo doc on a crate and then visually inspecting the generated HTML files...