`#[diagnostic::on_const]` needs better generic parameter handling.

[mejrs]

For example: playground

#![crate_type = "lib"]
#![feature(diagnostic_on_const, const_trait_impl)]

pub struct X<A, B> {
    field: (A, B),
}

pub const trait Y<Z> {
    fn blah(&self) {}
}

#[diagnostic::on_const(note = "Self = {Self}, Z = {Z}, A = {A}, B = {B}")]
impl<Z, A, B> Y<Z> for X<A, B> {}

const _: () = {
    X {
        field: (42_u8, "hello"),
    }
    .blah();
};

Compiler output:

  = note: Self = X<u8, &str>, Z = _, A = {A}, B = {B}

• I expect it should be able to print A and B, since they're concrete in this scenario.
• Is it right to print Z = _?
• There's also no lint for if you try to format a generic that isn't anywhere on the trait, impl, or adt.

[rperier]

@rustbot claim

[rperier]

Hi, the code that checks if #[diagnostic::on_const] is applied to a non-const trait impl in compiler/rustc_passes/src/check_attr.rs in the method check_diagnostic_on_const, could probably be moved to compiler/rustc_attr_parsing/src/attributes/diagnostic/on_const.rs, like it's already done for other attributes. What do you think ?

[mejrs]

We don't have that information there, hir::Target doesn't have the constness (nor the generic params for that matter).

[lcnr]

Hi, the code that checks if #[diagnostic::on_const] is applied to a non-const trait impl in compiler/rustc_passes/src/check_attr.rs in the method check_diagnostic_on_const, could probably be moved to compiler/rustc_attr_parsing/src/attributes/diagnostic/on_const.rs, like it's already done for other attributes. What do you think ?

cc @jdonszelmann @JonathanBrouwer as I'd assume we want to change attribute handling to also be aware of constness potentially?

[mejrs]

cc @jdonszelmann @JonathanBrouwer as I'd assume we want to change attribute handling to also be aware of constness potentially?

I'm leaning towards no on this:

• all attributes on functions would need to write out Allow(Target::Fn {konst: true}),Allow(Target::Fn{konst: false}) etc
• for diagnostic::on_const we still need the call in rustc_passes to check the generic parameters
• maybe this would be different if we had a bunch of attributes that care about constness, i wouldnt change this for just two or three.