Compiler-internal lint for public libcore items not reexported in libstd

[meithecatte]

Inspired by #60185.

[Centril]

This sounds great to me; would love to save us the collective embarrassment =P

[nikomatsakis]

I'm not sure why this is tagged as T-compiler, removing that tag.

[nikomatsakis]

Also, it'd be great if somebody could elaborate on exactly what change is being suggested here =)

[jonas-schievink]

The idea is to have another internal lint in rustc that runs on libstd/libcore, and reject any public items in libcore that don't also exist in libstd at the same path.

The motivation is that 1.34.0 contained many stabilizations for libcore items, where the libstd reexport was forgotten (which can happen very easily).

(I tagged this as T-compiler since this lint would be implemented in rustc; the nomination makes more sense for T-libs to answer "do we even want this?")

[SimonSapin]

The libs team discussed this at yesterday’s triage meeting. We agreed that this sounds good to have, but none of us volunteered to implement it :)

[pnkfelix]

Tagging as T-compiler and nominating for discussion at the T-compiler meeting, in order to determine priority and maybe try to find a mentor?

[jonas-schievink]

Perhaps the Clippy folks may be interested in mentoring this?

[alexcrichton]

The libs team agrees that this would be a nice-to-have, but we don't have much more to say about it.

[pnkfelix]

discussed briefly at T-compiler meeting. P-medium. Un-nominating.

[oli-obk]

Doing this as a lint seems... very hard. There's no (nice?) way to iterate over the public API of a crate afaik. So when compiling libstd, I don't know how we can find out what is missing.

[SimonSapin]

This doesn’t have to be in rustc’s actual linting infrastructure. It could be any code that we can run from ./x.py test, for example a script that looks at rustdoc output.