Undocumented Attributes

[ehuss]

There are a few attributes that are currently not documented. I wanted to get feedback if these should be documented. I've included my inclination, but I'd like to hear what others think.

• [x] automatically_derived — I vote "probably"? It has some use in the wild. I think the only reason to use it is for rustdoc. Are there other reasons to use it?
• [x] feature — I vote "maybe" 🤔? Although this is a nightly-oriented attribute, it is very widely used.
• [x] type_length_limit — I vote "yes". I think it is analogous to recursion_limit, and I suspect it just fell through the cracks.
• bench — I vote "no". It requires the unstable Bencher to be used. (Now destabilized via https://github.com/rust-lang/rust/pull/62507)
• reexport_test_harness_main — I vote "no". Even though it is usable on stable, I think it is an internal implementation detail, and I do not see anyone using it.

These are just waiting to be finished:

• [x] panic_handler (#362)
• [x] used (#361)
• [x] target_feature (#286)

[petrochenkov]

automatically_derived is also an implementation detail, I don't know why it's not feature gated.

[Centril]

automatically_derived — I vote "probably"? It has some use in the wild. I think the only reason to use it is for rustdoc. Are there other reasons to use it?

What does the attribute do?

@petrochenkov Could you try a PR + crater to "destabilization"?

bench — I vote "no". It requires the unstable Bencher to be used.

👍

feature — I vote "maybe" 🤔? Although this is a nightly-oriented attribute, it is very widely used.

👍 + note that it is unstable.

reexport_test_harness_main — I vote "no". Even though it is usable on stable, I think it is an internal implementation detail, and I do not see anyone using it.

What... @petrochenkov I'd also attempt destabilization for this...

type_length_limit — I vote "yes". I think it is analogous to recursion_limit, and I suspect it just fell through the cracks.

Sounds good.

These are just waiting to be finished:

@ehuss I think these PRs haven't received any attention for some time, if you would like to take over them that'd be nice.

[ehuss]

What does the attribute do?

Hm, looking closer, I'm not sure. rustdoc used to use it to separate automatically derived traits, but it was removed in https://github.com/rust-lang/rust/pull/34105. Just grepping through the code shows a few uses:

• Avoids unused warnings.
• Something about unsafety checks.
• Clippy uses it for some lints.

Here's a sampling of crates that use it in the wild:

• alga_derive
• aster
• bart_derive
• bit_manager_derive
• clippy_lints
• drop-take-derive
• enum-kinds
• enum-kinds-macros
• enum-map-derive
• enum_traits_macros
• eosio_macros
• gluon_codegen
• log4rs-rolling-file
• nue-codegen
• palette_derive
• runtime-fmt-derive
• serde_codegen
• serde_derive
• serde_derive_state
• serde_yaml_incomplete

if you would like to take over them that'd be nice.

Yea, I'll try to take a look. I think Jorge said he's busy with thesis work.

[Centril]

Something about unsafety checks.

That sounds concerning...

Here's a sampling of crates that use it in the wild:

Oh... wow; That seems quite unfortunate... Might be unfeasible to destabilize, maybe we should try to clarify semantics instead then...

[ehuss]

That sounds concerning...

Here it is used to display a warning diagnostic if #[derive] is used on something that uses #[repr(packed)] that doesn't implement Copy. Seems a bit presumptuous that all derives will do something unsafe, but I'm not going to read the long discussion where it was introduced (https://github.com/rust-lang/rust/pull/44884). SAFE_PACKED_BORROWS says it will become a hard error in the future.

[Havvy]

This can be closed, yes?

[ehuss]

Yea. I seem to recall leaving it open for some reason, but now I can't remember.