rustc_marker_type built in attribute created to have certain marker types not trigger dead code warnings from clippy by asder8215 · Pull Request #154978 · rust-lang/rust

asder8215 · 2026-04-08T06:29:57Z

This PR fixes the issue on PhantomPinned triggering field is never read warning by clippy through a built in attribute called rustc_marker_type.

A few questions I have are:

If a built in attribute approach is okay to use here, should I extend this attribute to all the other Phantom* types?
Currently, I have every change I made into 1 commit. Should I separate the changes I made for compiler and the changes I made for clippy into different commits?
Does a built in attribute like this have uses outside of being internal to the standard library? I'm wondering if people create marker types and wish to not have dead code warnings on them.

Note: This is my first time contributing to the compiler side of Rust repos, so I'm unsure if I'm doing anything wrong with making a built in attribute. I'm just going based off my intuition from go to references in my IDE on what everything is doing.

cc @clarfonthey

rustbot · 2026-04-08T06:30:03Z

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

rustbot · 2026-04-08T06:30:05Z

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 69 candidates
Random selection from 10 candidates

asder8215 · 2026-04-09T08:38:08Z

src/tools/clippy/tests/ui-toml/pub_underscore_fields/pub_underscore_fields.rs

-use std::marker::PhantomData;

 pub mod inner {
-    use std::marker;


View changes since the review

For some reason, it kept telling me that it couldn't find std::marker crate, so I couldn't shortcut the field types to marker::PhantomPinned/marker::PhantomData<T>.

I'm not sure how this test operated prior to this, or if I screwed up something to cause this issue.

asder8215 · 2026-04-09T08:41:06Z

src/tools/clippy/clippy_utils/src/attrs.rs

 }

+/// Checks whether a given result of a name resolution are marked as `#[rustc_marker_type]`
+pub fn has_rustc_marker_type_attr(tcx: TyCtxt<'_>, res: &Res) -> bool {


View changes since the review

After hours of exploring how attributes works in the compiler, I figured out that the DefId that I could get from a field type's basic result (if it doesn't Err) could inform me about whether that field type has a specific attribute associated with it. If there's a better way to do this than the way I'm doing it, I'm all ears; I'm not even sure if this is the idiomatic way of getting an attribute from a specific type.

asder8215 · 2026-04-09T08:46:44Z

compiler/rustc_hir/src/attrs/data_structures.rs

    RustcMain,

+    /// Represents `#[rustc_marker_type]`
+    RustcMarkerType(Symbol, Span),


View changes since the review

I'm not sure if this is correct. I took inspiration from other enum members written like this (like Lang or RustcAsPtr). I do know that it operates with attribute parsing from lint_helpers.rs and I assume that lets us know what symbol name represents this AttributeKind, whether duplicate of the attribute applied to a certain target produces a compiler error, what target is this attribute limited to. I'm unsure what create does specifically. My hunch tells me that it's related to whether the attribute macro takes an argument or not, but unsure; if that's the case, I might just not need any arguments as part of this enum member.

asder8215 · 2026-04-09T08:48:02Z

compiler/rustc_attr_parsing/src/attributes/lint_helpers.rs

 }

+pub(crate) struct RustcMarkerTypeParser;
+impl<S: Stage> NoArgsAttributeParser<S> for RustcMarkerTypeParser {


View changes since the review

Let me know if this is the correct place to place this sort of attribute. I assumed that because rustc_marker_type helped clippy with dead field warnings, it should be part of lint_helpers.rs

asder8215 · 2026-04-09T08:48:42Z

compiler/rustc_feature/src/builtin_attrs.rs

    ),
    rustc_attr!(rustc_force_inline,"`#[rustc_force_inline]` forces a free function to be inlined"),
    rustc_attr!(rustc_scalable_vector,"`#[rustc_scalable_vector]` defines a scalable vector type"),
+    rustc_attr!( rustc_marker_type, "the `#[rustc_marker_type]` attribute is used by the standard library to mark certain marker types \


View changes since the review

Also, let me know if this is the correct spot to put the rustc_attr! for rustc_marker_type. It's in miscellaneous right now.

rustbot · 2026-04-10T05:54:23Z

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

…ypes not trigger dead code warnings from clippy

rustbot · 2026-04-10T20:03:01Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

rustbot assigned davidtwco Apr 8, 2026