| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
- [x] Removed `?const` and change uses of `?const`
- [x] Added `~const` to the AST. It is gated behind const_trait_impl.
- [x] Validate `~const` in ast_validation.
- [ ] Add enum `BoundConstness` to the HIR. (With variants `NotConst` and
`ConstIfConst` allowing future extensions)
- [ ] Adjust trait selection and pre-existing code to use `BoundConstness`.
- [ ] Optional steps (*for this PR, obviously*)
- [ ] Fix #88155
- [ ] Do something with constness bounds in chalk
|
|
Previously, rustdoc was making lots of copies of temporary owned values.
Now, it uses the owned value wherever possible.
|
|
rustdoc: Move Cache from Context to SharedContext
r? `@camelid`
|
|
This can happen when a tag is opened after the length limit is reached;
the tag will not end up being added to `unclosed_tags` because the queue
will never be flushed. So, now, if the `unclosed_tags` stack is empty,
`close_tag()` does nothing.
This change fixes a panic in the `limit_0` unit test.
|
|
|
|
|
|
|
|
|
|
|
|
The length limit turns out to be a surprisingly good heuristic for
initial allocation size. See here for more details [1].
[1]: https://github.com/rust-lang/rust/pull/88173#discussion_r692531631
|
|
|
|
This commit refactors the implementation of
`markdown_summary_with_limit()`, separating the logic of determining
when the limit has been reached from the actual rendering process.
The main advantage of the new approach is that it guarantees that all
HTML tags are closed, whereas the previous implementation could generate
tags that were never closed. It also ensures that no empty tags are
generated (e.g., `<em></em>`).
The new implementation consists of a general-purpose struct
`HtmlWithLimit` that manages the length-limiting logic and a function
`markdown_summary_with_limit()` that renders Markdown to HTML using the
struct.
|
|
[rustdoc] Wrap code blocks in <code> tag
This PR modifies Rustdoc output so that fenced code snippets, items and whole file source codes are wrapped in `<pre><code>` instead of just `<pre>`. This should improve the semantic meaning of the generated content.
I'm not sure what to do about `render_attributes_in_pre` and `render_attributes_in_code`. These functions were clearly expected to be used for things inside `<pre>` or `<code>`, and since I added `<code>` in this PR, some of them will be used in a different context than before. However, it seems to me that even before they were not consistent. For example, `item_constant` used `render_attributes_in_code` for its attributes, however there was no `<code>` used for constants before this PR...
Should I create some `rustdoc-gui` tests? For example to check that all `<pre>` tags have a `<code>` child?
Fixes: https://github.com/rust-lang/rust/issues/88020
|
|
|
|
Add background-color on clickable definitions in source code
Someone suggested to add a decoration on clickable elements in the source code pages:
The idea is to not disturb the reading while telling the reader "you can click on this one", which is why it's not a text decoration.
What do you think `@rust-lang/rustdoc` ?
r? `@Nemo157`
|
|
|
|
|
|
[rustdoc] Copy only item path to clipboard rather than full `use` statement.
The (somewhat) recent addition of the "copy item import to clipboard" button is extremely nice.
However, i tend to write my code with fully qualified paths wherever feasible and only resort to `use` statements as a refactoring pass. This makes the "copy to clipboard" workflow awkward to use, as i would be copy-pasting that as, say
```rust
impl use std::ops::Add; for MyType {
```
and then go back and remove the `use ` and `;`.
This PR removes the `use ;` decorations, making it much nicer to use for fully-qualified items. I argue, however, that this does not noticeably degrade experience for those who prefer to import items, since the hard part about those is getting the path right, and writing the `use ;` decoration can be done by hand with little effort.
|
|
|
|
Closes #87828
The issue seems to stem from #87210 where code headings were changed from a heading containing code to a heading with the `code-header` class. `rustdoc.css` was updated, but `ayu.css` was missed.
|
|
|
|
|
|
|
|
map builder
|
|
* Add Classifier::new_light_span to wrap LightSpan::new_in_file constructor
|
|
|
|
|
|
|
|
|
|
|
|
struct for better readability
|
|
|
|
|
|
* Rename Span::wrap to Span::wrap_raw
* Improve documentation for Span::wrap_raw
|
|
* Add documentation on new arguments/functions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
don't use .into() to convert types to identical types (clippy::useless_conversion)
Example:
let _x: String = String::from("hello world").into();
|
|
|
|
|
|
|
|
This way, we can show the plus and minus buttons on screens, while voice
control will read off actual words "Collapse" and "Expand" instead of reading
"open brace minus close brace" and "open brace plus close brace".
Part of #87059
|
|
(clippy::useless_conversion)
Example:
let _x: String = String::from("hello world").into();
|
|
more clippy::complexity fixes
(also a couple of clippy::perf fixes)
|
|
Add support for tuple struct field documentation
Fixes #42615.
This is #80320 updated to new codebase and with added tests.
Part of https://github.com/rust-lang/rust/issues/83255.
cc ```@camelid``` (since you were involved on the original PR).
r? ```@jyn514```
|
