[Amanieu]

Tracking issue: #135806

This PR changes the Phantom{Covariant,Contravariant,Invariant}(Lifetime) marker types so that they mirror the PhantomData type: they can now be constructed as unit structs, no longer need the awkward variance() constructor, and are treated the same way as PhantomData.

The compiler side adds 2 internal attributes:

• #[rustc_force_variance(covariant|contravariant|invariant|bivariant)] on a generic parameter sets the variance of that parameter and overrides the one inferred from fields. This also removes the requirement that this parameter is used within a struct, allowing for generics on a unit struct. This is used for UnsafeCell, CovariantUnsafeCell and PhantomData, removing the current list of special cases in the variance solver.
• #[rustc_phantom_marker] on a unit struct indicates that this type should be ignored by some lints and structural checks, listed below.

These checks were previously explicitly ignoring PhantomData fields, and have now been extended to ignore all #[rustc_phantom_marker] fields:

• DispatchFromDyn
• CoerceUnsized
• Reborrow
• FFI safety
• Unused field lint (dead_code)
• used_underscore_binding in clippy

These checks continue to be specific to PhantomData because it implies ownership of a T:

• Special casing in the old and new trait solvers which considers T for auto-traits.
• Special casing in dropck which includes T in the drop-check constraints.

Finally, the trait impls have been changed to be consistent with PhantomData: these types now have a const Default impl and a StructualPartialEq impl.

[Amanieu]

r? mejrs

[rustbot]

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

cc @jdonszelmann, @JonathanBrouwer

rustc_codegen_gcc is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_gcc instead.

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

Some changes occurred in compiler/rustc_attr_ir

cc @jdonszelmann, @JonathanBrouwer

[mejrs]

rustc_force_variance is unsound, with it you can write code such as:

#![feature(rustc_attrs)]
#![allow(internal_features)]

struct CovariantMutRef<'a, #[rustc_force_variance(covariant)] T> {
    data: &'a mut T,
}

fn main() {
    let mut x: &'static str = "ferris";
    let long: CovariantMutRef<'_, &'static str> = CovariantMutRef { data: &mut x };
    {
        let y = String::from("corro");
        let short: CovariantMutRef<'_, &str> = long;
        *short.data = &y;
    }
    println!("{}", x);
}

produces:

error: Undefined Behavior: constructing invalid value of type &str: encountered a dangling reference (use-after-free)
  --> RUSTLIB/core/src/fmt/mod.rs:LL:CC
   |
LL |             fn fmt(&self, f: &mut Formatter<'_>) -> Result { $tr::fmt(&**self, f) }
   |                                                                       ^^^^^^^ Undefined Behavior occurred here
...
LL | fmt_refs! { Debug, Display, Octal, Binary, LowerHex, UpperHex, LowerExp, UpperExp }
   | ----------------------------------------------------------------------------------- in this macro invocation
   |
   = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior

While it's not a Big Deal since it's an internal attribute, I think it ought to be addressed:

• someone might at some point end up using it in a std data structure and accidentally expose such an unsoundness
• I'm not entirely sure what CovariantUnsafeCell needs to do to be sound. I think it is currently sound because of the absence of a &mut T -> &mut CovariantUnsafeCell<T> method? It would be nice to capture this in a safety comment somewhere.

I suspect the easiest fix is to just make the attribute unsafe.

Can you also add a feature gate test for both attributes?

View changes since this review

[mejrs]

Can you add a test for this?

[Amanieu]

I'll make the attribute unsafe and add the test.

These attributes shouldn't get a feature gate: they are internal and never going to be stabilized. There is no point in giving them a separate tracking issue.

Improving the docs of CovariantUnsafeCell is outside the scope of this PR. But the basic idea is that for a MyCell<T>:

• It must be covariant if exposes a read-like API: fn read(&self) -> T<'a> can allow 'a to be shortened but not lengthened.
• It must be contravariant if it exposes a write-like API: fn write(&self, val: T<'a>) can allow 'a to be lengthened but not shortened.
• Having both APIs required invariance.

[mejrs]

These attributes shouldn't get a feature gate: they are internal and never going to be stabilized. There is no point in giving them a separate tracking issue.

No, I mean a test checking that they can't be used without #![feature(rustc_attrs)]

[rustbot]

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.

[rust-bors]

☔ The latest upstream changes (presumably #165056) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.