Stream: rustdoc

Topic: Showing the version a function was stabilized as `const`


view this post on Zulip CraftSpider (Nov 30 2020 at 00:15):

Picked it up, threaded const_stable_since through all the rendering, now waiting to see what tests fail / where I'll need to add new tests.

view this post on Zulip Joshua Nelson (Nov 30 2020 at 00:15):

that sounds awesome :D

view this post on Zulip Joshua Nelson (Nov 30 2020 at 00:16):

as a start I recommend running x.py doc --stage 1 library/std --open and making sure it looks decent

view this post on Zulip CraftSpider (Nov 30 2020 at 00:38):

Thanks. Implementation thoughts: 4 cases: (None, None), (Some(v), None), (None, Some(cv)), and (Some(v), Some(cv). This assumes 'None' also includes the condition containing != ver and !ver.is_empty(). The case for all but one is trivial, but one case is unsure: const version is some, stable is None. Maybe just display 'const: X.X' instead of 'X.X (const: Y.Y)'?

view this post on Zulip Joshua Nelson (Nov 30 2020 at 00:39):

this is an internal attribute, so I would just error out if it has const_since but not stable

view this post on Zulip Joshua Nelson (Nov 30 2020 at 00:39):

if you run into errors with that, they should be fixed, not displayed :P

view this post on Zulip Joshua Nelson (Nov 30 2020 at 00:40):

see https://github.com/rust-lang/rust/pull/76143/ for an example of adding a new error

view this post on Zulip CraftSpider (Nov 30 2020 at 00:44):

I'm more thinking the case where it is stable, but stable ver == containing_stable_ver, EG Result is stable from 1.0, and is_some is stable from 1.0, but it's const stable from after. Because currently, that displays nothing, so should it start displaying that duplicate information?

view this post on Zulip Joshua Nelson (Nov 30 2020 at 00:46):

I might be misreading: you're thinking of the case when an API was stabilized as const at the same time it was stabilized? But that doesn't match your second sentence.

view this post on Zulip CraftSpider (Nov 30 2020 at 00:50):

Let me give a pseudocode example:

#[stable(version = "1.0")]
impl SomeStruct {
    #[const_stable(version = "1.50")]
    #[stable(version = "1.0")]
    fn is_fooey() -> bool { ... }
}

Existing code displays no 'stable since' on the function, because stable_version is the same as containing_stable_version. How should the new code handle this case?

view this post on Zulip Joshua Nelson (Nov 30 2020 at 00:51):

oh I see - currently, the stable annotation is deduplicated on is_fooey because it's also present on the impl

view this post on Zulip CraftSpider (Nov 30 2020 at 00:51):

Exactly. Should I start displaying it, or should I only display a const: X.X to not add duplication?

view this post on Zulip Joshua Nelson (Nov 30 2020 at 00:51):

I would show both to avoid ambiguity, I think: X.X (const Y.Y)

view this post on Zulip CraftSpider (Nov 30 2020 at 00:52):

Alright, I'll do that

view this post on Zulip Joshua Nelson (Nov 30 2020 at 00:52):

cc @RalfJ - does that match your expectations?

view this post on Zulip CraftSpider (Nov 30 2020 at 01:00):

image.png
With that behavior

view this post on Zulip Joshua Nelson (Nov 30 2020 at 01:01):

looks great :heart:

view this post on Zulip CraftSpider (Nov 30 2020 at 02:26):

Question: How does rustdoc handle emission of errors? In from_def_id_and_parts, do I emit an error with the cx.tcx.error() like in a normal rustc situation?

view this post on Zulip Joshua Nelson (Nov 30 2020 at 02:28):

yes, that's fine

view this post on Zulip Joshua Nelson (Nov 30 2020 at 02:29):

if you're feeling really ambitious you can add a new error code

view this post on Zulip CraftSpider (Nov 30 2020 at 02:35):

That would be an interesting time, and I'd probably want to do that in the rustc side I imagine. Make it a rule that 'const_stable' must be 'stable'.

view this post on Zulip Joshua Nelson (Nov 30 2020 at 02:36):

if you want to do that in a follow-up, I'm 100% ok with that

view this post on Zulip Joshua Nelson (Nov 30 2020 at 02:36):

since I don't think it's enforced currently

view this post on Zulip CraftSpider (Nov 30 2020 at 02:38):

Yeah, I think a follow-up would be good. I'll add a comment to the pull mentioning it, and write up an issue if one isn't already out there. Unrelated: Wish Intellij-Rust obeyed #![feature(rustc_private)], the alternative I've found is repeatedly adding them all to cargo, then commenting it out before running tests so it doesn't rebuild them as deps

view this post on Zulip Joshua Nelson (Nov 30 2020 at 02:38):

actually, yeah, let's do that

view this post on Zulip Joshua Nelson (Nov 30 2020 at 02:38):

if it helps, rust-analyzer works well with rustc_private IME

view this post on Zulip RalfJ (Nov 30 2020 at 10:22):

Joshua Nelson said:

cc RalfJ - does that match your expectations?

I don't have any expectations^^ happy to leave UI design up to you here

view this post on Zulip Joshua Nelson (Nov 30 2020 at 12:30):

Well, it certainly seems good enough for a first draft, if people complain it's easy to change. I think I like it as-is, though.

view this post on Zulip Joshua Nelson (Dec 02 2020 at 17:51):

looks pretty good :)
image.png

view this post on Zulip apiraino (Dec 02 2020 at 17:52):

definitively nice :)


Last updated: Oct 11 2021 at 22:34 UTC