Add T to PhantomData impl Debug

[Stargateur]

This add debug information for PhantomData, I believe it's make sense to add this to debug impl of PhantomData since T is what define what is the PhantomData just write "PhantomData" is not very useful for debugging.

Alternative:

• PhantomData::<{}>
• PhantomData { t: "str_type" }

@rustbot label +T-libs-api -T-libs

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[bjorn3]

A counter argument to this change is that we don't include T for None either.

[Stargateur]

A counter argument to this change is that we don't include T for None either.

We never include generic type in any implementation of Debug however PhantomData is very special, I don't think we can compare it to Option, when you have None you have no value so you shouldn't care of T, PhantomData represent a "linked" type, it's always here, but PhantomData doesn't have a field so we don't show it.

A use case of PhantomData I often use is to implement different behavior based on T. For example:

#[derive(Clone, Debug, Default, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub struct First;

#[derive(Clone, Debug, Default, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub struct Last;

#[derive(Clone, Debug, Default, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub struct OneContext<Behavior, Context> {
  behavior: PhantomData<Behavior>,
  context: Context,
}

impl<Context> BitOr for OneContext<First, Context> {
  type Output = Self;

  fn bitor(self, _rhs: Self) -> Self::Output {
    self
  }
}

impl<Context> BitOr for OneContext<Last, Context> {
  type Output = Self;

  fn bitor(self, rhs: Self) -> Self::Output {
    rhs
  }
}

Here First and Last represent a behavior I want to implement, either keep the initial value or the lastest value given to bitor. While you print debug of OneContext you only have PhantomData, it doesn't allow to know what is the behavior whereas PhantomData<First> would allow it.

This kind of use of PhantomData is common and I think show the type of T is useful for it.

[Mark-Simulacrum]

Hm, I have somewhat mixed feelings on a change like this. I think it's true that this information can be useful, but it's also somewhat of an unusual thing for us to do -- most generic types don't include generic information in their print out.

I think overall I'm net-positive on this change, and it seems like something that we could revert in the future, but I'd like to get another set of eyes on it. Let's r? @joshtriplett

[joshtriplett]

This seems useful to me, to the extent that it's useful for PhantomData to show up in Debug at all.

On the other hand, I suspect that PhantomData is also a type that many structures would want to skip in Debug given an attribute allowing the #[derive(Debug)] to do so.

[joshtriplett]

@bors r+

[bors]

📌 Commit eac1e30 has been approved by joshtriplett

It is now in the queue for this repository.

[bors]

⌛ Testing commit eac1e30 with merge 1f1defc...

[bors]

☀️ Test successful - checks-actions
Approved by: joshtriplett
Pushing 1f1defc to master...

[rust-timer]

Finished benchmarking commit (1f1defc): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	0.7%	[0.7%, 0.7%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.7%	[0.7%, 0.7%]	1

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.4%	[2.2%, 6.3%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.0%	[-2.8%, -1.3%]	4
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Footnotes

1. the arithmetic mean of the percent change ↩ ↩²

2. number of relevant changes ↩ ↩²