| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
It's not clear why it was done, and apparently it's no longer necessary now.
Such additions are unpredictable for early doc link resolution and would force us to collect all doc links from all external traits.
|
|
|
|
|
|
I think `@hasraw` is slightly clearer than `@hastext` since it is
actually matching against the raw HTML, not the text nodes.
|
|
|
|
For some reason, adding some text to match against makes this test pass.
Before, when it was *more* general, it was failing!
This seems very likely to be a bug in htmldocck, which I'm going to
investigate.
|
|
This issue was most likely fixed by #93805.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rustdoc: Stop textually replacing `Self` in doc links before resolving them
Resolve it directly to a type / def-id instead.
Also never pass `Self` to `Resolver`, it is useless because it's guaranteed that no resolution will be found.
This is a pre-requisite for https://github.com/rust-lang/rust/issues/83761.
|
|
|
|
|
|
|
|
Fixes #93428
This fix is a response to a couple of special cases related to the
`module_id`, which is eventually used for trait candidates:
* The module id is always set to the current crate, when checking `crate::`.
Normally, the set of in-scope traits would be set in `load_links_in_attrs`,
but if there are no doc comments, then that loop will never run.
* the module id is set to the parent module, when resolving a module
that is spelled like this:
// Notice how we use an outlined doc comment here!
// [`Test::my_fn`]
mod something {
}
As with the above problem with `crate::`, we need to make sure the
module gets its traits in scope resolved, even if it has no doc comments
of its own.
|
|
rustdoc: fix intra-link for generic trait impls
fixes #92662
r? `````@camelid`````
|
|
|
|
|
|
Inherent associated types *are* supported, just unstable.
|
|
|
|
|
|
Fixes #90703
|
|
Improve rustdoc layout
This is an overtake of https://github.com/rust-lang/rust/pull/89385 originally written by `@cynecx.`
I kept the original commit and simply added the missing fixes into a new one. You can test it online [here](https://rustdoc.crud.net/imperio/improve-rustdoc-layout/std/index.html).
r? `@jsha`
|
|
|
|
Now that compiletest denies warnings in these tests, they need fixing!
|
|
Windows on Macos ARM64 produce linker errors.
|
|
- Fix broken handling of primitive associated items
- Remove fragment hack
Fixes 83083
- more logging
- Update CrateNum hacks
The CrateNum has no relation to where in the dependency tree the crate
is, only when it's loaded. Explicitly special-case core instead of
assuming it will be the first DefId.
- Update and add tests
- Cache calculation of primitive locations
This could possibly be avoided by passing a Cache into
collect_intra_doc_links; but that's a much larger change, and doesn't
seem valuable other than for this.
|
|
- All attributes for an item need to be considered at once, they can't
be considered a line at a time.
- The top-level crate was not being visited. This bug was caught by
`extern-crate-used-only-in-link`, which I'm very glad I added.
- Make the loader private to the module, so that only one function is
exposed.
|
|
This reverts commit 5f0c54db4e595a6a77048f2b0605138ffa49a326.
|
|
Improvements to intra-doc link macro disambiguators
A few small improvements around macro disambiguators:
- display the link text as it was entered: previously `[macro!()]` would be displayed without the parantheses (fixes #86309)
- support `!{}` and `![]` as macro disambiguators (fixes #86310)
r? `@jyn514` cc `@Manishearth` `@camelid`
|
|
|
|
|
|
|
|
rustdoc: link to stable/beta docs consistently in documentation
This is an alternative to https://github.com/rust-lang/rust/pull/84941 which fixes the problem consistently by linking to stable/beta for *all* items, not just for primitives.
## User-facing changes
- Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as).
- Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels).
- Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links.
Note that "links" includes both intra-doc links and rustdoc's own
automatically generated hyperlinks.
## Implementation changes
- Update the testsuite to allow linking to /beta and /1.52.1 in docs
- Use an html_root_url for the standard library that's dependent on the channel
This avoids linking to nightly docs on stable.
- Update rustdoc to use channel-dependent links for primitives from an
unknown crate
- Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync
- Include doc.rust-lang.org in the channel
cc Mark-Simulacrum - I know [you were dubious about this in the past](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Rustdoc.20unconditionally.20links.20to.20nightly.20libstd.20docs/near/231223124), but I'm not quite sure why? I see this as "just a bugfix", I don't know why rustdoc should unconditionally link to nightly.
cc dtolnay who commented in https://github.com/rust-lang/rust/issues/30693:
> I would welcome a PR to solve this permanently if anyone has ideas for how. I don't believe we need an RFC.
Fixes https://github.com/rust-lang/rust/issues/30693 (note that issue is marked as feature-accepted, although I don't see where it was discussed).
|
|
## User-facing changes
- Intra-doc links to primitives that currently go to rust-lang.org/nightly/std/primitive.x.html will start going to channel that rustdoc was built with. Nightly will continue going to /nightly; Beta will link to /beta; stable compilers will link to /1.52.1 (or whatever version they were built as).
- Cross-crate links from std to core currently go to /nightly unconditionally. They will start going to /1.52.0 on stable channels (but remain the same on nightly channels).
- Intra-crate links from std to std (or core to core) currently go to the same URL they are hosted at; they will continue to do so. Notably, this is different from everything else because it can preserve the distinction between /stable and /1.52.0 by using relative links.
Note that "links" includes both intra-doc links and rustdoc's own
automatically generated hyperlinks.
## Implementation changes
- Update the testsuite to allow linking to /beta and /1.52.1 in docs
- Use an html_root_url for the standard library that's dependent on the channel
This avoids linking to nightly docs on stable.
- Update rustdoc to use channel-dependent links for primitives from an
unknown crate
- Set DOC_RUST_LANG_ORG_CHANNEL from bootstrap to ensure it's in sync
- Include doc.rust-lang.org in the channel
|
|
- Don't duplicate DefKind -> ItemType handling; that's a good way to get bugs
- Use exhaustive match
- Add comments
This found that register_res is very wrong in at least one way: if it
registers a Res for `Variant`, it should also register one for `Field`.
But I don't know whether the one for Variant should be removed or Field
added. Maybe someone has ideas?
|
|
Instead of using a depth counter and adding "../" to get to the top,
this commit makes rustdoc actually compare the path of what it's
linking from to the path that it's linking to. This makes the resulting
HTML shorter.
Here's a comparison of one of the largest (non-source) files in the
Rust standard library docs (about 4% improvement before gzipping).
$ wc -c struct.Wrapping.old.html struct.Wrapping.new.html
2387389 struct.Wrapping.old.html
2298538 struct.Wrapping.new.html
Most if it can be efficiently gzipped away.
$ wc -c struct.Wrapping.old.html.gz struct.Wrapping.new.html.gz
70679 struct.Wrapping.old.html.gz
70050 struct.Wrapping.new.html.gz
But it also makes a difference in the final DOM size, reducing it from 91MiB to 82MiB.
|
|
Previously, rustdoc would panic on links to external crates if they were
surrounded by backticks.
|
|
rustdoc: Cleanup handling of associated items for intra-doc links
Helps with https://github.com/rust-lang/rust/issues/83761 (right now the uses of the resolver are all intermingled with uses of the tyctxt). Best reviewed one commit at a time.
r? ```@bugadani``` maybe? Feel free to reassign :)
|
|
Previously, the types looked like this:
- None means this is not an associated item (but may be a variant field)
- Some(Err) means this is known to be an error. I think the only way that can happen is if it resolved and but you had your own anchor.
- Some(Ok(_, None)) was impossible.
Now, this returns a nested Option and does the error handling and
fiddling with the side channel in the caller. As a side-effect, it also
removes duplicate error handling.
This has one small change in behavior, which is that
`resolve_primitive_associated_item` now goes through `variant_field` if
it fails to resolve something. This is not ideal, but since it will be
quickly rejected anyway, I think the performance hit is worth the
cleanup.
This also fixes a bug where struct fields would forget to set the side
channel, adds a test for the bug, and ignores `private_intra_doc_links`
in rustc_resolve (since it's always documented with
--document-private-items).
|
|
Don't report disambiguator error if link would have been ignored
Fixes #83859.
This prevents us from warning on links such as `<hello@example.com>`.
Note that we still warn on links such as `<hello@localhost>` because
they have no dots in them. However, the links will still work, even
though a warning is reported.
r? ````@jyn514````
|
|
This prevents us from warning on links such as `<hello@example.com>`.
Note that we still warn on links such as `<hello@localhost>` because
they have no dots in them. However, the links will still work, even
though a warning is reported.
|
|
This is step 2 towards fixing #77548.
In the codegen and codegen-units test suites, the `//` comment markers
were kept in order not to affect any source locations. This is because
these tests cannot be automatically `--bless`ed.
|
|
Instead, only load the crates that are linked to with intra-doc links.
This doesn't help very much with any of rustdoc's fundamental issues
with freezing the resolver, but it at least fixes a stable-to-stable
regression, and makes the crate loading model somewhat more consistent
with rustc's.
|
