Allow marker traits as additional traits on trait objects.

[beepster4096]

Currently, only auto traits are allowed to be extra traits on trait objects because they are guaranteed to have no functions. However, there is another type of trait that has this property: marker traits. It seems like an oversight that this is not allowed.

This PR fixes this.

Work left to do:

• See if this change is enough to make it work
• Change error message

[rust-highfive]

r? @oli-obk

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

[beepster4096]

Tests are passing, so this is ready for review

[oli-obk]

@bors r+

Makes sense to me and impl looks good.

[bors]

📌 Commit 7f03b70f471cd51466b6c6fc45bab58158970ffb has been approved by oli-obk

[jackh726]

Is this something we want to feature gate? Maybe not because marker traits are unstable anyways...

[beepster4096]

Technically, a crate could use this without feature flags by depending on a crate with a marker trait in it. I doubt this will cause problems however.

[Mark-Simulacrum]

I think at least we should cc @rust-lang/lang for awareness. I was going to suggest noting this on the tracking issue for marker traits, but that doesn't seem to exist -- I guess the other thing would be the tracking issue for "multi trait trait objects"? I think @nikomatsakis you were working with someone on that, maybe in wg-traits context?

[Mark-Simulacrum]

@bors r-

Can we squash the commits here, please? I was going to do it for you, but it looks like that may be disabled on your fork/this PR?

[nikomatsakis]

I agree with cc'ing lang on this =)

[cramertj]

What does is_marker currently mean here? Is it only specifically tagged traits, or is it all traits that have no methods? I remember discussing similar proposals before, and at the time I was concerned that "marker trait" wasn't a clear pre-existing user-visible term. I also am worried about the idea of making it a breaking change to add a single defaulted method to a trait that previously had no methods.

[scottmcm]

Assuming this is based on https://doc.rust-lang.org/nightly/unstable-book/language-features/marker-trait-attr.html (not just the trait being empty) then it seems plausible to me. The big question I'd have is around marker traits with supertraits -- it might need to be "#[marker] traits where all their supertraits are also #[marker]" or something.

[beepster4096]

That's a good point I didn't consider. This code doesn't check super traits because auto traits cannot have any.

[nikomatsakis]

What does is_marker currently mean here?

I believe @cramertj that marker traits currently require a #[marker] annotation (@scottmcm made this change in #53693).

[nikomatsakis]

I'm comfortable overall with this change, but I'm a bit nervous about exposing the word "marker trait" to end users in diagnostics.

[JohnCSimon]

I'm comfortable overall with this change, but I'm a bit nervous about exposing the word "marker trait" to end users in diagnostics.

ping from triage:
@drmeepster can you address this comment?
Please adjust the label with @rustbot ready when you're ready for another review

[rustbot]

Error: Parsing shortcut command in comment failed: ...'tbot ready' | error: expected end of command at >| ' when you''...

Please let @rust-lang/release know if you're having trouble with this bot.

[JohnCSimon]

ping again from triage:
@drmeepster can you address this comment?

[beepster4096]

Can't seem to figure out how to do this right, and not interested in spending any more time trying.