#[forbid(unused_qualifications)] is incompatible with all builtin derives

[jonas-schievink]

#![forbid(unused_qualifications)]

#[derive(Clone)]
pub struct S;

error[E0453]: allow(unused_qualifications) overruled by outer forbid(unused_qualifications)
 --> src/main.rs:3:10
  |
1 | #![forbid(unused_qualifications)]
  |           --------------------- `forbid` level set here
2 | 
3 | #[derive(Clone)]
  |          ^^^^^ overruled by previous forbid

All built-in custom derives put #[allow(unused_qualifications)] on the generated impl, but the forbid level can not be overridden by that.

Custom derives are not able to trigger the deprecated lint, despite not attaching #[allow(deprecated)], so maybe the same mechanism should be used for unused_qualifications?

[jonas-schievink]

Ah, the deprecation lint has this check:

rust/src/librustc_middle/middle/stability.rs

Lines 220 to 222 in 2454a68

	if span.in_derive_expansion() {
	return;
	}

[samrat]

@rustbot claim

[samrat]

If my understanding is correct, Derives(custom and builtin) will always be defined in a crate that will be external to the one using them. And it seems we turn off suggestions for lints originating from external crates:

rust/src/librustc_middle/lint.rs

Line 224 in 2454a68

// If this code originates in a foreign macro, aka something that this crate

My original approach to this issue was to avoid adding the #[allow(unused_qualifications)] to the impl and add a in_derive_expansion check in

rust/src/librustc_resolve/late.rs

Line 1844 in 2454a68

if path.len() > 1

but I couldn't figure out a case where the in_derive_expansion check makes a difference in the suggestion displayed(I did verify that the lint is captured in the lint_buffer in the case the unnecessary qualification is in an external crate, just not displayed).

Any thoughts on this approach, and suggestions on how I can go about testing this change?

[Alexendoo]

Triage: Hi, are you still working on this issue @samrat?

[samrat]

Hi @Alexendoo, I don't think I'll be able to devote sufficient time to work on this issue anytime soon.

[Alexendoo]

No problem

@rustbot release-assignment

[bugadani]

@rustbot claim

[dtolnay]

@rustbot release-assignment

[mdholloway]

I think @samrat had the right solution to this one. I'd be happy to pick it up and drag it over the finish line.

@rustbot claim