Stream: rustdoc

Topic: nominated: #81070


view this post on Zulip triagebot (Mar 06 2021 at 02:39):

@T-rustdoc issue #81070 "Incorrect span used for doctests defined using #[doc(include)] or #[doc = include_str!("...")]" has been nominated for T-rustdoc discussion.

view this post on Zulip Noah Lev (Mar 06 2021 at 02:39):

It works! :tada:

view this post on Zulip Noah Lev (Mar 06 2021 at 02:39):

Although for some reason I had to add T-rustdoc and I-nominated in the same label change for it to work. Probably a triagebot bug.

view this post on Zulip Noah Lev (Mar 06 2021 at 02:40):

I nominated this because I think we should decide whether we want the source location to be based on the position of the doc(include)/doc=include_str! or based on the position in the included file. Then once we decide which location it should use we should fix the bugs.

view this post on Zulip Noah Lev (Mar 06 2021 at 02:42):

Like the OP, I think I lean towards using the position in the included file, though I'm not sure how feasible that would be for doc=include_str! since IIUC the macro expansion happens before rustdoc runs.

view this post on Zulip Joshua Nelson (Mar 24 2021 at 04:19):

using the place in the included file seems fine

view this post on Zulip triagebot (Apr 28 2021 at 12:31):

@T-rustdoc issue #81070 "Incorrect span used for doctests defined using #[doc(include)] or #[doc = include_str!("...")]" has been nominated for T-rustdoc discussion.

view this post on Zulip Joshua Nelson (Apr 28 2021 at 14:38):

@Camelid I think triagebot has a bug, it should only have pinged once

view this post on Zulip Joshua Nelson (Apr 28 2021 at 14:38):

Can you turn off the ping until it's fixed to avoid spam?

view this post on Zulip Joshua Nelson (Apr 28 2021 at 14:40):

Oh it's because @apiraino added T-rustdoc

view this post on Zulip Joshua Nelson (Apr 28 2021 at 14:41):

@Manish Goregaokar are you sure the second label is worth it? If we run into another place where rustdoc should be consulted but not involved in the FCP we can just remove the label temporarily

view this post on Zulip apiraino (Apr 28 2021 at 14:42):

yes it was me. I thought the issue should have that label but GuillaumeGomez instructed me that from now the rustdoc team will prefer A-rustdoc when the issue/pr does not need to be discussed by the whole team (iiuc)

view this post on Zulip Manish Goregaokar (Apr 28 2021 at 15:23):

@Joshua Nelson only one of the labels should ping imo

view this post on Zulip Joshua Nelson (Apr 28 2021 at 15:45):

Right yes, this happened because all the T-rustdoc labels got switched to A-rustdoc and then apiraino added back T-rustdoc.

view this post on Zulip Joshua Nelson (Apr 28 2021 at 15:46):

I think it's confusing to have both

view this post on Zulip apiraino (Apr 28 2021 at 15:57):

I can revert my change, ofc (I did the wrong)

view this post on Zulip Joshua Nelson (Apr 28 2021 at 16:49):

@apiraino nah I think it's fine

view this post on Zulip Noah Lev (Apr 29 2021 at 20:31):

Joshua Nelson said:

Manish Goregaokar are you sure the second label is worth it? If we run into another place where rustdoc should be consulted but not involved in the FCP we can just remove the label temporarily

Yeah, I think it's confusing to have two labels, especially since other teams only use one. I've also noticed people labeling issues with T-rustdoc because that's what we always used to do.

view this post on Zulip Noah Lev (Apr 29 2021 at 20:32):

We could also consider keeping A-rustdoc but only using it for triaging PRs that had it automatically added.

view this post on Zulip Noah Lev (Apr 29 2021 at 20:32):

But I think we should only have one human-applied label.

view this post on Zulip Manish Goregaokar (Apr 29 2021 at 22:06):

@Camelid I think that label should be A-rustdoc and we use T-rustdoc when we need robots to do the thing

view this post on Zulip Manish Goregaokar (Apr 29 2021 at 22:06):

@Joshua Nelson all the other teams handle this this way

view this post on Zulip Manish Goregaokar (Apr 29 2021 at 22:06):

i'm unclear why it's broken for us

view this post on Zulip Manish Goregaokar (Apr 29 2021 at 22:15):

The core issue is that we've been using the tool wrong for ages, and if we ever want to autolabel our PRs, this will be a problem

view this post on Zulip Joshua Nelson (Apr 30 2021 at 00:42):

Manish Goregaokar said:

Joshua Nelson all the other teams handle this this way

I don't think they do? there's no A-compiler label or anything like that

view this post on Zulip Noah Lev (Apr 30 2021 at 02:24):

Manish Goregaokar said:

Camelid I think that label should be A-rustdoc and we use T-rustdoc when we need robots to do the thing

Yeah, other teams use T-: T-compiler, T-libs, T-libs-impl

Clippy and Rustfmt use A- labels, but they're out of tree, whereas (currently) rustdoc is in-tree.

view this post on Zulip triagebot (May 07 2021 at 22:18):

@T-rustdoc issue #81070 "Incorrect span used for doctests defined using #[doc(include)] or #[doc = include_str!("...")]" has been nominated for T-rustdoc discussion.

view this post on Zulip Noah Lev (May 07 2021 at 22:19):

Sorry for the ping; I just re-added T-rustdoc to the issue because this is a decision concerning the team, which is I think what T-rustdoc is for :)

view this post on Zulip Noah Lev (May 07 2021 at 22:19):

(I kept A-rustdoc too.)

view this post on Zulip Noah Lev (May 07 2021 at 22:21):

There was some discussion here before regarding A-rustdoc vs T-rustdoc which I moved into its own topic as it's not related to this nominated issue: https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/A-rustdoc.20vs.20T-rustdoc

view this post on Zulip apiraino (Jun 30 2021 at 17:12):

@T-rustdoc this issue still looks I-nominated but I've lost track if it was actually discussed or not :-)

view this post on Zulip GuillaumeGomez (Jun 30 2021 at 18:43):

It wasn't as far as I know


Last updated: Oct 11 2021 at 22:34 UTC