Remove support for compiler plugins.

[nnethercote]

They've been deprecated for four years.

This commit includes the following changes.

• It eliminates the rustc_plugin_impl crate.
• It changes the language used for lints in compiler/rustc_driver_impl/src/lib.rs and compiler/rustc_lint/src/context.rs. External lints are now called "loaded" lints, rather than "plugins" to avoid confusion with the old plugins. This only has a tiny effect on the output of -W help.
• E0457 and E0498 are no longer used.
• E0463 is narrowed, now only relating to unfound crates, not plugins.
• The plugin feature was moved from "active" to "removed".
• It removes the entire plugins chapter from the unstable book.
• It removes quite a few tests, mostly all of those in tests/ui-fulldeps/plugin/.

Closes #29597.

r? @ghost

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Some changes occurred in src/tools/rust-analyzer

cc @rust-lang/rust-analyzer

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[nnethercote]

I decided to implement the removal to see what it looked like, and to encourage a decision. I did a lot of grepping to catch as much relevant code as possible. There are still plenty of "plugin" mentions for things like linker plugins, which are different.

An FCP will be needed before this can merge, at the minimum.

Cargo will need some adjustment, to remove the plugin = true option under [lib]. src/doc/book/redirects/compiler-plugins.md will also need adjustment to avoid some test failures.

Servo is often given as a reason for keeping plugin support, but @SimonSapin said this 18 months ago:

Activity in the Servo project has been low lately and will be in the forseeable future. If a better API becomes available, it’s not clear when or if we’d be able to migrate the GC rooting lint to it. Given this, I feel it’s probably not fair to expect rustc to indefinitely keep the burden of maintaining plugin support for Servo’s sake.

Servo has become more active again recently. I don't know if that has any impact on the decision. Four years of deprecation is a long time!

[lnicola]

Given that this is a no-op and we're currently unable to do syncs, would you mind dropping this change and optionally filing it against the RA repo?

[nnethercote]

Sure, if this PR is approved I can do that.

[compiler-errors]

I think the PR description justifies the removal, but also see this zulip thread for justification.

@rfcbot fcp merge

[rfcbot]

Team member @compiler-errors has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Aaron1011
• @cjgillot
• @compiler-errors
• @davidtwco
• @eddyb
• @estebank
• @jackh726
• @lcnr
• @matthewjasper
• @michaelwoerister
• @nagisa
• @oli-obk
• @petrochenkov
• @pnkfelix
• @wesleywiser

Concerns:

• servo-buy-in resolved by Remove support for compiler plugins. #116412 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[petrochenkov]

@rfcbot concern servo-buy-in

The main (and only?) reason why this feature wasn't removed several years ago is its servo use case.
It needs to be explicitly confirmed that either servo can migrate to something else, or can remove its lints, or is no longer important enough to care about.

[petrochenkov]

@rfcbot concern servo-buy-in

[matthewjasper]

previous attempt at this: #64675

[bors]

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

[nnethercote]

Servo is often given as a reason for keeping plugin support, but @SimonSapin said this 18 months ago:

Activity in the Servo project has been low lately and will be in the forseeable future. If a better API becomes available, it’s not clear when or if we’d be able to migrate the GC rooting lint to it. Given this, I feel it’s probably not fair to expect rustc to indefinitely keep the burden of maintaining plugin support for Servo’s sake.

Servo has become more active again recently. I don't know if that has any impact on the decision. Four years of deprecation is a long time!

cc some Servo people for input: @mrobinson, @emilio, @mukilan, @sagudev, @jdm, @Manishearth

[Manishearth]

It's still used in servo for GC safety, yes, and people have been actively working on Servo again.

It is possible servo could move to one of the custom lint frameworks out there, or potentially turn this into a clippy restriction lint (sufficiently generic with attributes so that others can use it)

[jdm]

Yeah, I don't think anything has really changed here from what's been previously articulated in #64675. Obviously it would be easier for Servo if this removal didn't happen, but I recognize that the project holds much less influence over the process than it once did (and that's probably a good thing, to be honest). We had a discussion about whether a linter alternative could work in https://servo.zulipchat.com/#narrow/stream/263398-general/topic/Dylint.

[nnethercote]

Right, so we're in a "nothing has changed in three years" situation. I'm really hoping to avoid having this long-deprecated, long-unmaintained feature kept around indefinitely.

[workingjubilee]

Servo will have 100% buy-in on putting in the necessary maintenance work, one way or another, if it is removed now and they wish to use a stable version of 1.75, or the nightly immediately after this lands.

There are many reasons to smooth a transition path for users of nightly features, but the existing grace period has been exceptional.

[Manishearth]

I will say, while servo is the only permanent user that I know of, having a permaunstable plugin API like this has been useful at various times and imo is a good thing to have. Similarly, clang has the unstable clang plugin API that a lot of tools use.

I'd be surprised if this were a maintenance burden: to me "it's been around for years and nobody has tried to remove it yet" feels more due to it not getting in the way of anything, but I could be wrong. servo hasn't had major pull in the rust project for ages so I'd be surprised if the reason was that it did get in the way but people decided not to remove it because of servo.

(while I'm still somewhat biased here; I will note that I haven't written code on servo/servo for ages and wouldn't be directly affected by this decision. I'm just a fan of us having such an API. I've found both the rust and clang plugin APIs to be super useful for various operations)

[workingjubilee]

I'd be surprised if this were a maintenance burden: to me "it's been around for years and nobody has tried to remove it yet" feels more due to it not getting in the way of anything, but I could be wrong. servo hasn't had major pull in the rust project for ages so I'd be surprised if the reason was that it did get in the way but people decided not to remove it because of servo.

It is actually absurdly annoying to have around, and I have complained about it periodically, because the tests are almost always failing on actual local builds on platforms that aren't x86-64 Linux in my experience, which tricks contributors into thinking they broke something. And I have no idea why that only happens in local builds and not in the test suite, It Just Does, somehow. It greatly inconvenienced me the entire time I was trying to contribute to Rust while using Windows as my OS. I at some point stopped using Windows, but I have had to repeatedly reassure other contributors that no, they didn't break anything. If I had the courage and knowledge to do so, then, I would've opened this very same PR years ago.

So yes, this is exactly why. Literally, petrochenkov raised a concern based on this reason.

No one is maintaining this interface, that I am aware of, and rustc wrappers like your very own clippy actually work in a cross-platform way, and are capable of more besides.

[Manishearth]

Okay, thanks, in which case I feel comfortable about having this removed. I think such a feature would be valuable to have in the long run, I agree that it should be maintained and should not be retained if it is at all a current maintenance burden, which it clearly is.

(And future attempts to re-add this can refer to this thread to understand what things need to be resolved for such a feature to be Good)

[sagudev]

I think servo should no longer be problematic, I made prototype in servo/servo#30508 (with all of our lints ported), now I only need to polish integration with servo. It would be nice if this PR waited for servo/servo#30508 to land in servo (which should be in a week).

[rust-timer]

Finished benchmarking commit (5020f7c): comparison URL.

Overall result: ✅ improvements - 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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-10.1%	[-23.2%, -0.9%]	8
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-10.1%	[-23.2%, -0.9%]	8

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.4%	[1.1%, 1.8%]	3
Improvements ✅ (primary)	-2.1%	[-3.5%, -0.7%]	4
Improvements ✅ (secondary)	-1.1%	[-1.5%, -0.5%]	5
All ❌✅ (primary)	-2.1%	[-3.5%, -0.7%]	4

Cycles

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-9.3%	[-19.0%, -1.9%]	7
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-9.3%	[-19.0%, -1.9%]	7

Binary size

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

Bootstrap: 635.435s -> 634.085s (-0.21%)
Artifact size: 304.48 MiB -> 304.52 MiB (0.02%)

[mati865]

Perf improvements are mostly noise.
Previously there was fictional regression in PR that only modified docs: https://perf.rust-lang.org/compare.html?start=9c20ddd956426d577d77cb3f57a7db2227a3c6e9&end=1bb6553b967b69eed9ed8147e78b4f65cfc48e11&stat=instructions:u
After this PR the regression has disappeared.

[nnethercote]

Postscript: @bjorn3's suggestion to move lint registration earlier was very useful. I did that in #117649, and it led to more clean-ups in #117993 and #118002. Combined with some recent related improvements I made in #117268, #117376, and #117475, and rustc_driver_impl::run_compiler and rustc_interface::interface::run_compiler are both looking quite a bit simpler and more readable than they used to. It's nice to see.