Rustdoc documents these with the name of the type alias instead of normalizing them to the underlying type.
Use associated types instead so that the generated docs for nightly-rustc are easier to read.
Optimize `Wtf8Buf::into_string` for the case where it contains UTF-8.
Add a `is_known_utf8` flag to `Wtf8Buf`, which tracks whether the
string is known to contain UTF-8. This is efficiently computed in many
common situations, such as when a `Wtf8Buf` is constructed from a `String`
or `&str`, or with `Wtf8Buf::from_wide` which is already doing UTF-16
decoding and already checking for surrogates.
This makes `OsString::into_string` O(1) rather than O(N) on Windows in
common cases.
And, it eliminates the need to scan through the string for surrogates in
`Args::next` and `Vars::next`, because the strings are already being
translated with `Wtf8Buf::from_wide`.
Many things on Windows construct `OsString`s with `Wtf8Buf::from_wide`,
such as `DirEntry::file_name` and `fs::read_link`, so with this patch,
users of those functions can subsequently call `.into_string()` without
paying for an extra scan through the string for surrogates.
r? `@ghost`
According to [blame], this rule was added to support enum struct
variants. However, enum struct variants don't use tables in their design
any more, so this rule does nothing.
[blame]: 87991d5f5d/src/librustdoc/html/static/css/rustdoc.css (L748)
fluent: mandate slug names to be prefixed by crate name
This is currently only convention, but not actively checked for.
Additionally, improve error messages to highlight the path of the offending fluent file rather than the identifier preceding it.
This will conflict with #100671, so I'll leave it as draft until that's merged.
Rootless podman creates a separate user namespace, where an inner
`LOCAL_USER_ID` will map to a different subuid range on the host.
The "keep-id" mode maps the current UID directly into the container.
This makes `src/ci/docker/run.sh` work better for testing container
images on systems running podman, where "docker" is just a shim.
Move Error trait into core
This PR moves the error trait from the standard library into a new unstable `error` module within the core library. The goal of this PR is to help unify error reporting across the std and no_std ecosystems, as well as open the door to integrating the error trait into the panic reporting system when reporting panics whose source is an errors (such as via `expect`).
This PR is a rewrite of https://github.com/rust-lang/rust/pull/90328 using new compiler features that have been added to support error in core.
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.
