cargo-check-external-types treates #[doc(hidden)] private API used in pin_project_lite v0.2.15 as public API

[lalitb]

After upgrading pin_project_lite to version 0.2.15 (from version 0.2.14), I noticed that the external_type_check tool flags our code due to the exposure of an internal type, specifically PinnedFieldsOf. This occurs as we use the pin_project! macro on a struct that is part of the public API.

This behavior did not occur with the older version 0.2.14), and the same code passed the external_type_check tool without any issues. I’m trying to understand whether this change is an intended behavior in the newer versions ofpin_project_lite or if there might be a recommended approach to avoid this exposure.

Failure CI logs - https://github.com/open-telemetry/opentelemetry-rust/actions/runs/11505633091/job/32027766191?pr=2239

error: Unapproved external type `pin_project_lite::__private::PinnedFieldsOf` referenced in public API
   --> opentelemetry/src/trace/context.rs:363:1
    |
363 | pin_project! {
    | ...
371 | }␊
    | ^
    |
    = in where bound of `opentelemetry::trace::WithContext`
``

[taiki-e]

Thanks for the report. That's of course not public API, as it's path describes. Somehow a bug in rustdoc (or cargo-check-external-types) seems to cause #[doc(hidden)] thing to be treated like a public API.

https://github.com/taiki-e/pin-project-lite/blob/2b1715dbf7eb48c2fc7f9f469536d7e10846bb7e/src/lib.rs#L1665-L1668 https://github.com/taiki-e/pin-project-lite/blob/2b1715dbf7eb48c2fc7f9f469536d7e10846bb7e/src/lib.rs#L1681-L1682

I think the workaround would be to put it on the allow list, stating that it is a bug in rustdoc (or cargo-check-external-types). I remember there was a similar bug before. https://github.com/taiki-e/assert-unmoved/commit/bcf6d62b0676ae6284dcda841797b806b8f6a3e7#diff-b4d0ddb1e930f489ffb66816d754a1a7f34cb59bdcad1ab9a994e3382e8e7a91R11-R12

[taiki-e]

cc @jdisanti