Re-add raw_pointer_derive lint as a no-op

[brson]

Removed in #29882, causing breakage to maidsafe_utilities.

I recall at some point we decided never to remove lints because of this very problem and simply convert them to no-ops.

[brson]

Policy-wise this is similar but (imo) different to our policy of allowing changes to lints to break code. E.g. cap-lints won't affect removed lints.

[alexcrichton]

It looks like the breakage is due to unknown_lints which is itself a lint, so this seems like it's covered by our lint changes policy. Along those lines I can't actually think of a technical reason for why we'd want to not remove lints?

I do vaguely recall reaching the conclusion at some point, however, about not removing lints. I don't remember the reason, however, so I'd want to discuss this a bit before reverting.

[brson]

Two more crates broke in the latest report.

[bluss]

Don't we have a cargo feature that ensures that warnings (lints) changes are of very low impact, i.e. don't really break things that depend on the crate, for example.

[sfackler]

Yep, lints are capped at allowed for dependencies. Changing this one to be a no-op and maybe adding a default-warn noop-lints lint or whatever seems like a good idea though. It seems excessive to stop compilation instead of just warning when this kind of thing happens.

[brson]

Another regression popped up in this report. accumulator-0.1.3

[brson]

Also containerof-0.2.1, memory_map-0.0.3.

Edit: oh accumulator and memory_map were already known from a previous report. I think containerof is new.

[brson]

After updating the regression sheet I count 7 crates affected by this.

[brson]

@nikomatsakis and I discussed that we'd prefer removed lints indicate they were removed with a warning instead of saying 'unknown lint'. I may try to get a patch together that does this.

[pnkfelix]

triage: P-high

(it is questionable about whether this should be classified as a "regression" per se, in terms of what the impact actually is of this sort of change if you aren't opting into stronger lint settings. but anyway, we want to handle this case better.)

[nikomatsakis]

It seems there is a mechanism for registering that a lint has been removed, why didn't we use that? I think we ought to.

[brson]

I will try adding it back as a removed lint and making sure it doesn't cause build failures.

[brson]

I've gotten in to yak shaving with the code for registering renamed and removed lints. It doesn't have test coverage and has some issues. Still expect to get a patch in.

[nikomatsakis]

Is this not fixed?

[nikomatsakis]

@brson ^^ :)

[alexcrichton]

Done in #30878