| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
rustdoc: use strategic boxing to shrink `clean::Item`
* `inline_stmt_id` is never a cross-crate DefId, so save space by not storing it.
* Instead of two inner boxes for `Item`, use one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rustdoc-json: discard non-local inherent impls for primitives
Fixes #114039
at least it should
r? `@aDotInTheVoid`
|
|
|
|
Rustdoc often has to special-case `Self` because it is, well, a special
type of generic parameter (although it also behaves as an alias in
concrete impls). Instead of spreading this special-casing throughout the
code base, create a new variant of the `clean::Type` enum that is for
`Self` types.
This is a refactoring that has almost no impact on rustdoc's behavior,
except that `&Self`, `(Self,)`, `&[Self]`, and other similar occurrences
of `Self` no longer link to the wrapping type (reference primitive,
tuple primitive, etc.) as regular generics do. I felt this made more
sense since users would expect `Self` to link to the containing trait or
aliased type (though those are usually expanded), not the primitive that
is wrapping it. For an example of the change, see the docs for
`std::alloc::Allocator::by_ref`.
|
|
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
|
|
|
|
As suggested [on zulip][1], there's no need to use `GenericBound` here,
as the only bound a lifetime can have is that it outlives other
lifetimes.
While we're making breaking changes here, I also renamed it from using
"region" to "lifetime", as this is more user-aligned. See [this
comment][2] for details.
[1]: https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/.60ItemEnum.3A.3AOpaqueTy.60/near/448871430
[2]: https://github.com/rust-lang/rust/issues/100961#issuecomment-2206565556
|
|
|
|
|
|
|
|
r=compiler-errors
Rename HIR `TypeBinding` to `AssocItemConstraint` and related cleanup
Rename `hir::TypeBinding` and `ast::AssocConstraint` to `AssocItemConstraint` and update all items and locals using the old terminology.
Motivation: The terminology *type binding* is extremely outdated. "Type bindings" not only include constraints on associated *types* but also on associated *constants* (feature `associated_const_equality`) and on RPITITs of associated *functions* (feature `return_type_notation`). Hence the word *item* in the new name. Furthermore, the word *binding* commonly refers to a mapping from a binder/identifier to a "value" for some definition of "value". Its use in "type binding" made sense when equality constraints (e.g., `AssocTy = Ty`) were the only kind of associated item constraint. Nowadays however, we also have *associated type bounds* (e.g., `AssocTy: Bound`) for which the term *binding* doesn't make sense.
---
Old terminology (HIR, rustdoc):
```
`TypeBinding`: (associated) type binding
├── `Constraint`: associated type bound
└── `Equality`: (associated) equality constraint (?)
├── `Ty`: (associated) type binding
└── `Const`: associated const equality (constraint)
```
Old terminology (AST, abbrev.):
```
`AssocConstraint`
├── `Bound`
└── `Equality`
├── `Ty`
└── `Const`
```
New terminology (AST, HIR, rustdoc):
```
`AssocItemConstraint`: associated item constraint
├── `Bound`: associated type bound
└── `Equality`: associated item equality constraint OR associated item binding (for short)
├── `Ty`: associated type equality constraint OR associated type binding (for short)
└── `Const`: associated const equality constraint OR associated const binding (for short)
```
r? compiler-errors
|
|
|
|
Almost all callers want this anyway, and now we can use it to also return fed bodies
|
|
|
|
|
|
|
|
source order even if early-bound params are present
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When these `Box<Generics>` types were introduced,
`Generics` was made with `Vec` and much larger.
Now that it's made with `ThinVec`, `Type` is bigger
and should be boxed instead.
|
|
r=GuillaumeGomez
rustdoc: hide `#[repr(transparent)]` if it isn't part of the public ABI
Fixes #90435.
This hides `#[repr(transparent)]` when the non-1-ZST field the struct is "transparent" over is private.
CC `@RalfJung`
Tentatively nominating it for the release notes, feel free to remove the nomination.
`@rustbot` label needs-fcp relnotes A-rustdoc-ui
|
|
|
|
[rustdoc] Show enum discrimant if it is a C-like variant
Fixes https://github.com/rust-lang/rust/issues/101337.
We currently display values for associated constant items in traits:
And we also display constant values like [here](file:///home/imperio/rust/rust/build/x86_64-unknown-linux-gnu/doc/std/f32/consts/constant.E.html).
I think that for coherency, we should display values of C-like enum variants.
With this change, it looks like this:
As for the display of the constant value itself, I used what we already have to keep coherency.
We display the C-like variants value in the following scenario:
1. It is a C-like variant with a value set => all the time
2. It is a C-like variant without a value set: All other variants are C-like variants and at least one them has its value set.
Here is the result in code:
```rust
// Ax and Bx value will be displayed.
enum A {
Ax = 12,
Bx,
}
// Ax and Bx value will not be displayed
enum B {
Ax,
Bx,
}
// Bx value will not be displayed
enum C {
Ax(u32),
Bx,
}
// Bx value will not be displayed, Cx value will be displayed.
#[repr(u32)]
enum D {
Ax(u32),
Bx,
Cx = 12,
}
```
r? `@notriddle`
|
|
|
|
|
|
|
|
rustdoc: show inner enum and struct in type definition for concrete type
This PR implements the [Display enum variants for generic enum in type def page](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Display.20enum.20variants.20for.20generic.20enum.20in.20type.20def.20page) #rustdoc/zulip proposal.
This proposal comes from looking at [`TyKind`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/sty/type.TyKind.html) typedef from the compiler. On that page, the documentation is able to show the layout for each variant, but not the variants themselves. This proposal suggests showing the fields and variants for those "concrete type". This would mean that instead of having many unresolved generics, like in `IrTyKind`:
```rust
Array(I::Ty, I::Const),
Slice(I::Ty),
RawPtr(I::TypeAndMut),
Ref(I::Region, I::Ty, I::Mutability),
FnDef(I::DefId, I::GenericArgsRef),
```
those would be resolved with direct links to the proper types in the `TyKind` typedef page:
```rust
Array(Ty<'tcx>, Const<'tcx>),
Slice(Ty<'tcx>),
RawPtr(TypeAndMut<'tcx>),
Ref(Region<'tcx>, Ty<'tcx>, Mutability<'tcx>),
FnDef(DefId<'tcx>, GenericArgsRef<'tcx>),
```
Saving both time and confusion.
-----
<details>
<summary>Old description</summary>
I've chosen to add the enums and structs under the "Show Aliased Type" details, as well as showing the variants and fields under the usual "Variants" and "Fields" sections. ~~*under new the `Inner Variants` and `Inner Fields` sections (except for their names, they are identical to the one found in the enum, struct and union pages). Those sections are complementary and do not replace anything else.*~~
This PR proposes the following condition for showing the aliased type (basically, has the aliased type some generics that are all of them resolved):
- the typedef does NOT have any generics (modulo lifetimes)
- AND the aliased type has some generics
</details>
### Examples
```rust
pub enum IrTyKind<'a, I: Interner> {
/// Doc comment for AdtKind
AdtKind(&'a I::Adt),
/// and another one for TyKind
TyKind(I::Adt, I::Ty),
// no comment
StructKind { a: I::Adt, },
}
pub type TyKind<'a> = IrTyKind<'a, TyCtxt>;
```
<details>
<summary>Old</summary>
</details>
```rust
pub struct One<T> {
pub val: T,
#[doc(hidden)]
pub inner_tag: u64,
__hidden: T,
}
/// `One` with `u64` as payload
pub type OneU64 = One<u64>;
```
<details>
<summary>Old</summary>
</details>
r? `@GuillaumeGomez`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The default fn ret ty is always unit. Just use that.
Looking back at the time when `FnRetTy` (then called
`FunctionRetTy`) was first added to rustdoc, it seems to originally
be there because `-> !` was a special form: the never type didn't
exist back then.
https://github.com/rust-lang/rust/commit/eb01b17b06eb35542bb80ff7456043b0ed5572ba#diff-384affc1b4190940f114f3fcebbf969e7e18657a71ef9001da6b223a036687d9L921-L924
|
