restriction lint: `indirect_derive`

[lolbinarycat]

What it does

when enabled, this would produce a warning and suggestion whenever referring to a derive macro through a reexport instead of via the original package.

(optionally this would only trigger if the reexport is behind a feature flag, but i'm not sure how feasible that is)

Advantage

Enabling a derive feature flag has a slight overhead on compile times as it linearizes the dependency tree.

For example, building serde with the derive feature enabled means that serde and serde_derive can't be built in parallel.

This is something that often is done internally in the rust project, see rust-lang/rust#141989.
There is currently no automated way to refactor this, as it requires a level of namespace awareness that most (all?) IDEs lack.

Drawbacks

Some library crates may not want their _derive crates to be part of the public API for semver reasons.

May require adding a new entry to Cargo.toml

Example

use serde::Deserialize;

#[derive(Deserialize)]
struct Foo;

...

Could be written as:

use serde::Deserialize;

#[derive(serde_derive::Deserialize)]
struct Foo;
...