Trait HasCredentialMarkers 

pub trait HasCredentialMarkers {
    // Required method
    fn credential_markers() -> &'static [CredentialFieldMarker];
}

Trait that types deriving #[derive(plexus_macros::Credentials)] opt into by providing their static credential-marker slice.

Consumers do not implement this trait by hand; the #[derive(plexus_macros::Credentials)] macro emits the impl with the populated credential_markers() body. Types that do NOT derive Credentials do not implement this trait at all — instead, the #[plexus_macros::activation] call site dispatches to the blanket fallback CredentialsRegistryFallback which returns an empty slice.

Why a separate marker trait?

The autoref-specialization trick (see [CredentialsRegistryProbe]) uses TWO impls on CredentialsRegistryProbe<T>:

1. An inherent impl gated on T: HasCredentialMarkers — populated path.
2. A trait impl on &CredentialsRegistryProbe<T> — empty fallback path.

Inherent impls are constrained to the type’s home crate (orphan rule E0116); the user’s #[derive(Credentials)] cannot write impl CredentialsRegistryProbe<UserType> because CredentialsRegistryProbe lives in plexus_auth_core. The marker trait sidesteps this: the user’s derive emits a normal trait impl impl HasCredentialMarkers for UserType (orphan-allowed), and plexus_auth_core’s generic inherent impl impl<T: HasCredentialMarkers> CredentialsRegistryProbe<T> does the dispatch.

Required Methods

fn credential_markers() -> &'static [CredentialFieldMarker]

Return the static slice of credential-field markers for this type. Emitted by the #[derive(Credentials)] macro; not implemented by hand.

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementors