Missing tracking issue and label for `multiple_supertrait_upcastable`

[hashcatHitman]

Location (URL)

https://github.com/rust-lang/rust/issues
https://github.com/rust-lang/rfcs

Summary

The multiple_supertrait_upcastable feature gate is used to gate the allowed-by-default lint of the same name. Both were added in #105484. The lint is used within the compiler, but I've also seen it used in the wild. The wording of the lint explanation:

To support upcasting with multiple supertraits, we need to store multiple vtables and
this can result in extra space overhead, even if no code actually uses upcasting. This
lint allows users to identify when such scenarios occur and to decide whether the
additional overhead is justified.

...seems to suggest via the word "users" that this lint was intended to eventually be used by developers outside the compiler at their discretion.

I cannot find any tracking issue, RFC, or issue tracker label dedicated to either the lint or feature.

I am unsure if this is a mistake, the lint is intentionally permanently unstable, or if something else is the case. I tried asking about this on the Zulip (#t-compiler/diagnostics > Missing tracking issue for `multiple_supertrait_upcastable`?) but haven't received any responses.

I'm still not very familiar with Zulip, so I don't know if it is expected that no one would say anything this soon, but I wanted to make an issue about this before I forgot about it, just in case.

[zachs18]

In the compiler, the multiple_supertrait_upcastable feature is declared in the section for "internal feature gates (no tracking issue)", but it is declared as unstable, not internal, and the explanation listed in the lint's declaration is not specific to the stdlib or compiler.

I'll make a tracking issue and a PR to move the feature declaration to the "actual feature gates" section. If T-lang (who I think is in charge of lints?) wants to leave this as perma-unstable, we can just close the tracking issue and mark the feature as internal.