Skip to content

internal: turn PhantomPinned error into warnings#135

Open
nbdd0121 wants to merge 1 commit intomainfrom
dev/warn
Open

internal: turn PhantomPinned error into warnings#135
nbdd0121 wants to merge 1 commit intomainfrom
dev/warn

Conversation

@nbdd0121
Copy link
Copy Markdown
Member

The PhantomPinned detection is just a lint, and is emitted as an error because there is no compile_warning!() macro, and proc-macro-diagnostics is not stable.

Use of #[deprecated = ""] attribute to approximate custom proc-macro warnings. A new line is added before message for visual clarity.

An example warning with this trick looks like this:

warning: use of deprecated function `_::warn`:
         The field `pin` of type `PhantomPinned` only has an effect if it has the `#[pin]` attribute
 --> test.rs:9:5
  |
9 |     pin: marker::PhantomPinned,
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Closes #51

@nbdd0121 nbdd0121 requested a review from BennoLossin April 24, 2026 13:04
The `PhantomPinned` detection is just a lint, and is emitted as an error
because there is no `compile_warning!()` macro, and
`proc-macro-diagnostics` is not stable.

Use of `#[deprecated = ""]` attribute to approximate custom proc-macro
warnings. A new line is added before message for visual clarity.

An example warning with this trick looks like this:

    warning: use of deprecated function `_::warn`:
             The field `pin` of type `PhantomPinned` only has an effect if it has the `#[pin]` attribute
     --> test.rs:9:5
      |
    9 |     pin: marker::PhantomPinned,
      |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Suggested-by: Benno Lossin <lossin@kernel.org>
Link: #51
Signed-off-by: Gary Guo <gary@garyguo.net>
Copy link
Copy Markdown
Member

@BennoLossin BennoLossin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh this is a cool way to solve it! if there is a way to test that the level is warning in the ui tests, I'd prefer that, otherwise looks good :)

@nbdd0121
Copy link
Copy Markdown
Member Author

nbdd0121 commented May 1, 2026

One way to test warnings is to compile the test suite once with #[allow(warnings)] and once with #[deny(warnings)] and record the stderr for deny warnings.

Although, this does not look feasible with trybuild as there's no way to specify compiler flags and I don't want to duplicate tests. Currently warnings are still mentioned in stderr of the compile-fail test so I think that should be fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

PhantomPinned detection of #[pin_data] replaces original path with ::core::marker::PhantomPinned

2 participants