Experiment: mark derived Clone impls as const

[clarfonthey]

This is an attempt to lay the foundation for marking #[derive]d trait impls as const. Right now, only trivial Clone impls (*self) are marked as const, but in the future, more complicated impls like PartialEq and PartialOrd could be marked as const as well.

This mostly just modifies the TraitDef struct in rustc_builtin_macros to allow marking traits as const. For now, only the Clone implementations are marked as const since they're the simplest, to prove that the feature works.

This also augments the existing Clone derive test to check that the generated impls can be const.

[rust-highfive]

r? @estebank

(rust-highfive has picked a reviewer for you, use r? to override)

[clarfonthey]

Even though it currently builds and the test passes, I'm going to leave this marked as a draft since I think it still could use some feedback in terms of how it's done (this is my first time changing any compiler code) and also just, the way it works in general.

[estebank]

r? @oli-obk

[oli-obk]

does this show up in rustdoc?

[oli-obk]

The main problem with this approach is that it is a breaking change for

struct Foo;
impl Clone for Foo {
    fn clone(&self) -> Self { Foo }
}
#[derive(Clone)]
struct Bar(Foo);

Thus the only way we can ever really make derives work, is by opting in, meaning something like #[derive(const Clone)]. This has been discussed in https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/syntax.2Fgrammar.3A.20deriving.20const.20traits

The discussion there isn't yet clear on the syntax, so I'm not sure how to proceed here.

[clarfonthey]

That's very fair; I think that the #[derive(const Clone)] syntax would be simple enough to implement that it could be changed later once a proper syntax is decided, but I also would understand if the preference is to not do that.

As you probably noticed in the code itself, what is probably a bigger concern is how to annotate the derived Clone impls in the standard library specifically, since there's no proper way to annotate them with separate rustc_const_unstable features. Not really sure if the current approach is okay, and I don't think it's acceptable to force them all to be manually implemented if a separate attribute is desired.

[clarfonthey]

(Will properly rebase later; am glad the error messages improved.)

[bors]

☔ The latest upstream changes (presumably #94787) made this pull request unmergeable. Please resolve the merge conflicts.

[clarfonthey]

Gonna close since this needs a redesign anyway.