Fix rustc_parse_format precision & width spans
When a `precision`/`width` was `CountIsName - {:name$}` or `CountIs - {:10}` the `precision_span`/`width_span` was set to `None`
For `width` the name span in `CountIsName(_, name_span)` had its `.start` off by one
r? ``@fee1-dead`` / cc ``@PrestonFrom`` since this is similar to #99987
Migrate `rustc_plugin_impl` to `SessionDiagnostic`
Migration of the `rustc_plugin_impl` crate.
~Draft PR because it is blocked on #100694 for `#[fatal(...)]` support~ (this has been merged, and I've changed over to `#[diag(...)]` now too), but I would also like to know if what I did with `LoadPluginError` is okay, because all it does is display the error message from `libloading` ([See conversation on zulip](https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/.23100717.20diagnostic.20translation/near/294327843)). This crate is apparently for a deprecated feature which is used by servo, so I don't know how much this matters anyway.
InferCtxt tainted_by_errors_flag should be Option<ErrorGuaranteed>
Fixes#100321.
Use Cell<Option<ErrorGuaranteed>> to guarantee that we emit an error when that flag is set.
Do not re-parse function signatures to suggest generics
This PR uses the existing resolution rib infrastructure to channel the correct span information to suggest generic parameters. This allows to avoid re-parsing a function's source code.
Drive-by cleanup: this removes useless `FnItemRibKind` from late resolution ribs. All the use cases are already covered by `ItemRibKind` and `AssocItemRibKind` which have more precise semantics.
While the `provide_*` methods already short-circuit when a value has
been provided, there are times where an expensive computation is
needed to determine if the `provide_*` method can even be called.
Add some more highlighting configurations
The following can be enabled/disabled now in terms of highlighting:
- doc comment injection (enabled by default)
- punctuation highlighting (disabled by default)
- operator highlighting (enabled by default)
- punctuation specialized highlighting (disabled by default)
- operator specialized highlighting (disabled by default)
- macro call bang highlighting (disabled by default)
This PR also changes our `attribute` semantic token type to the `decorator` type which landed upstream (but not yet in lsp-types).
Specialized highlighting is disabled by default, as all clients will have to ship something to map these back to the standard punctuation/operator token (we do this in VSCode via the inheritance mapping for example). This is a lot of maintenance work, and not something every client wants to do, pushing that need to use the user. As this is a rather niche use in the first place this will just be disabled by default.
Punctuation highlighting is disabled by default, punctuation is usually something that can be done by the native syntactic highlighting of the client, so there is no loss in quality. The main reason for this though is that punctuation adds a lot of extra token data that we sent over, a lot of clients struggle with applying this, so disabling this improves the UX for a lot of people. Note that we still highlight punctuations with special meaning as that special entity, (the never type `!` will still be tagged as a builtin type if it occurs as such)
Separate highlighting of the macro call bang `!` is disabled by default, as I think people actually didn't like that change that much, though at the same time I feel like not many people even noticed that change (I prefer it be separate, but that's not enough reason for it to be enabled by default I believe :^) )
cc https://github.com/rust-lang/rust-analyzer/issues/12783https://github.com/rust-lang/rust-analyzer/issues/13066
