The angle brackets were not rendered, so code like this:
some_func: for<'a> fn(val: &'a i32) -> i32
would be rendered as:
some_func: fn'a(val: &'a i32) -> i32
However, rendering with angle brackets is still invalid syntax:
some_func: fn<'a>(val: &'a i32) -> i32
so now it renders correctly as:
some_func: for<'a> fn(val: &'a i32) -> i32
-----
However, note that this code:
some_trait: dyn for<'a> Trait<'a>
will still render as:
some_trait: dyn Trait<'a>
which is not invalid syntax, but is still unclear. Unfortunately I think
it's hard to fix that case because there isn't enough information in the
`rustdoc::clean::Type` that this code operates on. Perhaps that case can
be fixed in a later PR.
Fix rendering of stabilization version for trait implementors
Rustdoc compares an item's stabilization version with its parent's to not render it if they are the same. Here, the implementor was compared with itself, resulting in the stabilization version never getting shown.
This probably needs a test.
Fixes#80777.
r? `@jyn514`
Deprecate-in-future the constants superceded by RFC 2700
Successor to #78335, re-opened after addressing the issues tracked in #68490.
This PR makes use of the new ability to explicitly annotate an item as triggering the deprecated-in-future lint (via `rustc_deprecated(since="TBD"`, see #78381). We might call this *soft deprecation*; unlike with deprecation, users will *not* receive warnings when compiling code that uses these items *unless* they opt-in via `#[warn(deprecated_in_future)]`. Like deprecation, soft deprecation causes documentation to formally acknowledge that an item is marked for eventual deprecation (at a non-specific point in the future).
With this new ability, we can sidestep all debate about when or on what timeframe something ought to be deprecated; as long as we can agree that something ought to be deprecated, we can receive much of the benefits of deprecation with none of the drawbacks. For these items specifically, the libs team has already agreed that they should be deprecated (see https://github.com/rust-lang/rust/issues/68490#issuecomment-747022696).
Don't try to add nested predicate to Rustdoc auto-trait `ParamEnv`
Fixes#80233
We already have logic in `evaluate_predicates` that tries to add
unimplemented predicates to our `ParamEnv`. Trying to add a predicate
that already holds can lead to errors later on, since projection
will prefer trait candidates from the `ParamEnv` to predicates from an
impl.
rustdoc: Resolve `&str` as `str`
People almost always are referring to `&str`, not `str`, so this will
save a manual link resolve in many cases.
Note that we already accept `&` (resolves to `reference`) in intra-doc
links, so this shouldn't cause breakage.
r? `@jyn514`
rustdoc: Remove `*` intra-doc alias for `pointer`
It's not valid Rust code and it can easily be confused with a wildcard
glob pattern or something else. People can always use `pointer` instead,
so it's just removing an alias.
It hasn't hit stable yet (I think it's still on nightly), so it's okay
to remove it. (We can always add it back later if we change our mind
too.)
r? `@jyn514`
cc https://github.com/rust-lang/rust/pull/80885#discussion_r554622737
It's not valid Rust code and it can easily be confused with a wildcard
glob pattern or something else. People can always use `pointer` instead,
so it's just removing an alias.
It hasn't hit stable yet (I think it's still on nightly), so it's okay
to remove it. (We can always add it back later if we change our mind
too.)
People almost always are referring to `&str`, not `str`, so this will
save a manual link resolve in many cases.
Note that we already accept `&` (resolves to `reference`) in intra-doc
links, so this shouldn't cause breakage.
Rustdoc: Fix macros 2.0 and built-in derives being shown at the wrong path
Fixes#74355
- ~~waiting on author + draft PR since my code ought to be cleaned up _w.r.t._ the way I avoid the `.unwrap()`s:~~
- ~~dummy items may avoid the first `?`,~~
- ~~but within the module traversal some tests did fail (hence the second `?`), meaning the crate did not possess the exact path of the containing module (`extern` / `impl` blocks maybe? I'll look into that).~~
r? `@jyn514`
This adjusts the `rustdoc` trait impl collection path to preserve `Deref` impls
from other crates. This adds a first pass to map all of the `Deref` type to
target edges and then recursively preserves all targets.
Properly handle primitive disambiguators in rustdoc
Fixes#80559
r? ``@jyn514``
Is there a way to test that the generated intra-doc link is what I expect?
Fix tests that incorrectly used `!@has` instead of `@!has`
The command is ``@!has`,` not `!`@has`.` I don't think these checks were
doing anything before! Ideally we would accept `!`@has`` as well, or at
least fail tests that use `!`@has`.` The current behavior seems to be
silently ignoring the check, which is very confusing.
r? `@GuillaumeGomez`
The command is `@!has`, not `!@has`. I don't think these checks were
doing anything before! Ideally we would accept `!@has` as well, or at
least fail tests that use `!@has`. The current behavior seems to be
silently ignoring the check, which is very confusing.
Fix intra-doc links for non-path primitives
This does *not* currently work for associated items that are
auto-implemented by the compiler (e.g. `never::eq`), because they aren't
present in the source code. I plan to fix this in a follow-up PR.
Fixes https://github.com/rust-lang/rust/issues/63351 using the approach mentioned in https://github.com/rust-lang/rust/issues/63351#issuecomment-683352130.
r? `@Manishearth`
cc `@petrochenkov` - this makes `rustc_resolve::Res` public, is that ok? I'd just add an identical type alias in rustdoc if not, which seems a waste.
