| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
r=notriddle,Manishearth,flip1995
Reuse rustdoc's doc comment handling in Clippy
Moves `source_span_for_markdown_range` and `span_of_attrs` (renamed to `span_of_fragments`) to `rustc_resolve::rustdoc` so it can be used in Clippy
Fixes https://github.com/rust-lang/rust-clippy/issues/10277
Fixes https://github.com/rust-lang/rust-clippy/issues/5593
Fixes https://github.com/rust-lang/rust-clippy/issues/10263
Fixes https://github.com/rust-lang/rust-clippy/issues/2581
|
|
rustdoc: Add missing "Aliased type" title in the sidebar
Follow-up of https://github.com/rust-lang/rust/pull/115682.
The sections title are supposed to be present in the sidebar, we forgot to put this one so I added it into it. I also added the missing newly created `aliased-type` ID into the `DEFAULT_ID_MAP`.
r? `@notriddle`
|
|
Implement fallback for effect param
r? `@oli-obk` or `@lcnr`
tracking issue for this ongoing work: https://github.com/rust-lang/rust/issues/110395
|
|
|
|
|
|
|
|
rustdoc: add impl items from aliased type into sidebar
Follow-up of https://github.com/rust-lang/rust/pull/115201.
|
|
|
|
|
|
|
|
rustdoc: Change syntax for anonymous functions set in JS
This function is not very useful in itself but it slightly reduces the JS size so it's always that I suppose... No changes in behaviour.
r? `@notriddle`
|
|
|
|
|
|
r=GuillaumeGomez
rustdoc: list matching impls on type aliases
Fixes https://github.com/rust-lang/rust/issues/32077
Fixes #99952
Remake of https://github.com/rust-lang/rust/pull/112429
Partially reverts https://github.com/rust-lang/rust/pull/112543, but keeps the test case.
This version of the PR avoids the infinite loop by structurally matching types instead of using full unification. This version does not support type alias trait bounds, but the compiler does not enforce those anyway (https://github.com/rust-lang/rust/issues/21903).
r? `@GuillaumeGomez`
CC `@lcnr`
|
|
|
|
Add CL and CMD into to pdb debug info
Partial fix for https://github.com/rust-lang/rust/issues/96475
The Arg0 and CommandLineArgs of the MCTargetOptions cpp class are not set within https://github.com/rust-lang/rust/blob/bb548f964572f7fe652716f5897d9050a31c936e/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L378
This causes LLVM to not neither output any compiler path (cl) nor the arguments that were used when invoking it (cmd) in the PDB file.
This fix adds the missing information to the target machine so LLVM can use it.
|
|
r=GuillaumeGomez
rustdoc: remove unused ID `mainThemeStyle`
This was added in https://github.com/rust-lang/rust/pull/47620 and used to build the URL of the theme stylesheets. It isn't used any more, because https://github.com/rust-lang/rust/pull/101702 changed it so that the URL was supplied in a `<meta>` tag, which also provides the hashes of the files.
|
|
r=notriddle
rustdoc: Render private fields in tuple struct as `/* private fields */`
Reopening of https://github.com/rust-lang/rust/pull/110552. All that was missing was a test for the different cases so I added it into the second commit.
Description from the original PR:
> I've gotten some feedback that the current rustdoc rendering of...
>
> ```
> struct HasPrivateFields(_);
> ```
>
> ...is confusing, and I agree with that feedback, especially compared to the field struct case:
>
> ```
> struct HasPrivateFields { /* private fields */ }
> ```
>
> So this PR makes it so that when all of the fields of a tuple variant are private, just render it with the `/* private fields */` comment. We can't *always* render it like that, for example when there's a mix of private and public fields.
cc ````@jsha````
r? ````@notriddle````
|
|
Set Arg0 and CommandLineArgs in MCTargetoptions so LLVM outputs correct CL and CMD in LF_DEBUGINFO instead of empty/invalid values.
|
|
This was added in 003b2bc1c65251ec2fc80b78ed91c43fb35402ec and used to build
the URL of the theme stylesheets. It isn't used any more, because
f9e1f6ffdf03ec33cb29e20c88fc7bcc938c7f42 changed it so that the URL was
supplied in a `<meta>` tag, which also provides the hashes of the files.
|
|
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`
|
|
|
|
Use relative positions inside a SourceFile.
This allows to remove the normalization of start positions for hashing, and simplify allocation of global address space.
cc `@Zoxc`
|
|
|
|
|
|
When writing a type-driven search query in rustdoc, specifically one
with more than one query element, non-existent types become generic
parameters instead of auto-correcting (which is currently only done
for single-element queries) or giving no result. You can also force a
generic type parameter by writing `generic:T` (and can force it to not
use a generic type parameter with something like `struct:T` or whatever,
though if this happens it means the thing you're looking for doesn't
exist and will give you no results).
There is no syntax provided for specifying type constraints
for generic type parameters.
When you have a generic type parameter in a search query, it will only
match up with generic type parameters in the actual function, not
concrete types that match, not concrete types that implement a trait.
It also strictly matches based on when they're the same or different,
so `option<T>, option<U> -> option<U>` matches `Option::and`, but not
`Option::or`. Similarly, `option<T>, option<T> -> option<T>`` matches
`Option::or`, but not `Option::and`.
|
|
This allows us to use negative numbers for others purposes.
|
|
rustdoc: update comment in search.js for #107629
Addressing https://github.com/rust-lang/rust/pull/107629#issuecomment-1693460106
r? `@jsha`
|
|
|
|
[rustdoc] Fix type based search
Fixes https://github.com/rust-lang/rust/issues/114522.
The problem was a bit more tricky than I originally thought it would be: we only kept type ID and generics in short, but as soon as there was a full path in the user query, the element didn't get an ID anymore because the ID map didn't know about `x::y` (although it knew about `y`). So for this first problem, I instead always pass the element name to get the ID.
Then a new problem occurred: we actually needed to check if paths matched, otherwise whatever the path, as long as the "end types" match, it's all good. meaning, we needed to add path information, but to do so, we needed it to be added into the search index directly as there was no mapping between `"p"` and `"q"`.
I hope this explanation makes sense to someone else than me. ^^'
r? `@notriddle`
|
|
|
|
|
|
Skip rendering metadata strings from include_str!/include_bytes!
The const rendering code in rustdoc completely ignores consts from expansions, but the compiler was rendering all consts. So some consts (namely those from `include_bytes!`) were rendered then ignored.
Most of the diff here is from moving `print_const_expr` from rustdoc into `rustc_hir_pretty` so that it can be used in rustdoc and when building rmeta files.
|
|
r=GuillaumeGomez
rustdoc: correctly deal with self ty params when eliding default object lifetimes
Fixes #115179.
|
|
|
|
lifetimes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
|
|
|
|
|
|
This let's us handle a multitude of things for free:
- #[doc(hidden)]
- private fields/variants
- --document-private-items
- --document-hidden-items
And correct in the process the determination of "has stripped items" by
doing the same logic done by other ones.
|
|
|
|
|
