Minor changes to Ipv4Addr
Minor changes to Ipv4Addr
* Impl IntoInner rather than AsInner for Ipv4Addr
* Add some comments
* Add test to show endiannes of Ipv4Addr display
Add some timing info to rustdoc
There are various improvements, but the main one is to time each pass
that rustdoc performs (`rustdoc::passes`).
Before, these were the top five timings for `cargo doc` on the cargo
repository:
```
+---------------------------------+-----------+-----------------+----------+------------+
| Item | Self time | % of total time | Time | Item count |
+---------------------------------+-----------+-----------------+----------+------------+
| <unknown> | 854.70ms | 20.888 | 2.47s | 744823 |
+---------------------------------+-----------+-----------------+----------+------------+
| expand_crate | 795.29ms | 19.436 | 848.00ms | 1 |
+---------------------------------+-----------+-----------------+----------+------------+
| metadata_decode_entry | 256.73ms | 6.274 | 279.49ms | 518344 |
+---------------------------------+-----------+-----------------+----------+------------+
| resolve_crate | 240.56ms | 5.879 | 242.86ms | 1 |
+---------------------------------+-----------+-----------------+----------+------------+
| hir_lowering | 146.79ms | 3.587 | 146.79ms | 1 |
+---------------------------------+-----------+-----------------+----------+------------+
```
Now the timings are:
```
+---------------------------------+-----------+-----------------+----------+------------+
| Item | Self time | % of total time | Time | Item count |
+---------------------------------+-----------+-----------------+----------+------------+
| <unknown> | 1.40s | 22.662 | 3.73s | 771430 |
+---------------------------------+-----------+-----------------+----------+------------+
| collect-trait-impls | 1.34s | 21.672 | 2.87s | 1 |
+---------------------------------+-----------+-----------------+----------+------------+
| expand_crate | 1.21s | 19.577 | 1.28s | 1 |
+---------------------------------+-----------+-----------------+----------+------------+
| build extern trait impl | 704.66ms | 11.427 | 1.07s | 21893 |
+---------------------------------+-----------+-----------------+----------+------------+
| metadata_decode_entry | 354.84ms | 5.754 | 391.81ms | 544919 |
+---------------------------------+-----------+-----------------+----------+------------+
```
The goal is to help me debug regressions like https://github.com/rust-lang/rust/pull/74518#issuecomment-661498214 (currently I have _no_ idea what could have gone wrong).
r? @eddyb or @Mark-Simulacrum
Report an ambiguity if both modules and primitives are in scope for intra-doc links
Closes https://github.com/rust-lang/rust/issues/75381
- Add a new `prim@` disambiguator, since both modules and primitives are in the same namespace
- Refactor `report_ambiguity` into a closure
Additionally, I noticed that rustdoc would previously allow `[struct@char]` if `char` resolved to a primitive (not if it had a DefId). I fixed that and added a test case.
I also need to update libstd to use `prim@char` instead of `type@char`. If possible I would also like to refactor `ambiguity_error` to use `Disambiguator` instead of its own hand-rolled match - that ran into issues with `prim@` (I updated one and not the other) and it would be better for them to be in sync.
Use allow(unused_imports) instead of cfg(doc) for imports used only for intra-doc links
This prevents links from breaking when items are re-exported in a
different crate and the original isn't being documented.
Spotted in https://github.com/rust-lang/rust/pull/75832#discussion_r475275837 (thanks ollie!)
r? @ollie27
publish-toolstate: show more context on HTTP error
The default display for HTTPError in Python does not include the request body. For GitHub API, the body includes more details about the error (like rate limiting). This could help diagnosing errors like this: https://github.com/rust-lang/rust/pull/75815#issuecomment-678798158
Fix typo in documentation of i32 wrapping_abs()
Hi!
I was reading through the std library docs and noticed that this section flowed a bit oddly; comparing it against https://doc.rust-lang.org/std/primitive.i32.html#method.wrapping_div and https://doc.rust-lang.org/std/primitive.i32.html#method.wrapping_neg , I noticed that those two pieces of documentation used a semicolon here.
This is my first time submitting a PR to this repo. Am I doing this right? Are tiny typo-fix PRs like this worth submitting, or are they not a good use of time?
Thank you!
Switch to intra-doc links in `std::macros`
Part of #75080.
---
* Switch to intra-doc links in `std::macros`
* Fix typo in module docs
* Link to `std::io::stderr` instead of `std::io::Stderr` to match the
link text
* Link to `std::io::stdout`
---
@rustbot modify labels: A-intra-doc-links T-doc T-rustdoc
- Add a new `prim@` disambiguator, since both modules and primitives are
in the same namespace
- Refactor `report_ambiguity` into a closure
Additionally, I noticed that rustdoc would previously allow
`[struct@char]` if `char` resolved to a primitive (not if it had a
DefId). I fixed that and added a test case.
Fix intra-doc links for associated items
@Manishearth and I found that links of the following sort are broken:
```rust
$ cat str_from.rs
/// [`String::from`]
pub fn foo() {}
$ rustdoc str_from.rs
warning: `[String::from]` cannot be resolved, ignoring it.
--> str_from.rs:4:6
|
4 | /// [`String::from`]
| ^^^^^^^^^^^^^^ cannot be resolved, ignoring
```
It turns out this is because the current implementation only looks at inherent impls (`impl Bar {}`) and traits _for the item being documented_. Note that this is not the same as the item being _linked_ to. So this code would work:
```rust
pub trait T1 {
fn method();
}
pub struct S;
impl T1 for S {
/// [S::method] on method
fn method() {}
}
```
but putting the documentation on `trait T1` would not.
~~I realized that writing it up that my fix is only partially correct: It removes the inherent impls code when it should instead remove the `trait_item` code.~~ Fixed.
Additionally, I discovered while writing this there is some ambiguity: you could have multiple methods with the same name, but for different traits:
```rust
pub trait T1 {
fn method();
}
pub trait T2 {
fn method();
}
/// See [S::method]
pub struct S;
```
Rustdoc should give an ambiguity error here, but since there is currently no way to disambiguate the traits (https://github.com/rust-lang/rust/issues/74563) it does not (https://github.com/rust-lang/rust/pull/74489#issuecomment-673878404).
There is a _third_ ambiguity that pops up: What if the trait is generic and is implemented multiple times with different generic parameters? In this case, my fix does not do very well: it thinks there is only one trait instantiated and links to that trait:
```
/// [`String::from`] -- this resolves to https://doc.rust-lang.org/nightly/alloc/string/struct.String.html#method.from
pub fn foo() {}
```
However, every `From` implementation has a method called `from`! So the browser picks a random one. This is not the desired behavior, but it's not clear how to avoid it.
To be consistent with the rest of intra-doc links, this only resolves associated items from traits that are in scope. This required changes to rustc_resolve to work cross-crate; the relevant commits are prefixed with `resolve: `. As a bonus, considering only traits in scope is slightly faster. To avoid re-calculating the traits over and over, rustdoc uses a cache to store the traits in scope for a given module.
Provide better spans for the match arm without tail expression
Resolves#75418.
Applied the same logic in the `if`-`else` type mismatch case.
r? @estebank
