| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix weird js condition
While going around the code, I found this weird condition. Fixing also affects the generated results in some cases apparently (could only find this one).
Any idea maybe `@notriddle?`
r? `@notriddle`
|
|
Add new eslint checks
r? ```@Dylan-DPC```
|
|
once cell renamings
This PR does the renamings proposed in https://github.com/rust-lang/rust/issues/74465#issuecomment-1153703128
- Move/rename `lazy::{OnceCell, Lazy}` to `cell::{OnceCell, LazyCell}`
- Move/rename `lazy::{SyncOnceCell, SyncLazy}` to `sync::{OnceLock, LazyLock}`
(I used `Lazy...` instead of `...Lazy` as it seems to be more consistent, easier to pronounce, etc)
```@rustbot``` label +T-libs-api -T-libs
|
|
|
|
* no-sequences
* no-throw-literal
|
|
|
|
Improve the tuple and unit trait docs
* Reduce duplicate impls; show only the `(T,)` and include a sentence saying that there exists ones up to twelve of them.
* Show `Copy` and `Clone`.
* Show auto traits like `Send` and `Sync`, and blanket impls like `Any`.
Here's the new version:
* <https://notriddle.com/notriddle-rustdoc-test/std/primitive.tuple.html>
* <https://notriddle.com/notriddle-rustdoc-test/std/primitive.unit.html>
|
|
r=notriddle
Fix sidebar items expand collapse
The collapse/expand event was not working for the items in the source code viewer sidebar (talking about these items:
).
This PR fixes it and adds a GUI test to prevent another regression.
r? ```@notriddle```
|
|
|
|
This is 682889fb06591c4245422b73b005c5d8ae2d0cad but for tuples. The
reasoning is the same:
* This commit also changes it so that tuples with all-generic elements still
link to the primitive.tuple.html page, just like slices. So there still
plenty of on-ramps for anybody who doesn't know about it.
* It's too hard to see when round braces are a separate link from the type
inside of them.
* It's too hard to click even if you do notice them.
|
|
|
|
Since #97668 was merged, the slice::get function now looks like this:
That whole thing, `[T]`, is a single link to `primitive.slice.html`. This
definitely fixes it for this case, but it's not obvious what we should do for
slices of concrete types:
There are actually three links in that `[u8]`: the opening brace `[` is a
link to `primitive.slice.html`, the `u8` is a link to `primitive.u8.html`,
and the final `]` is a link to `primitive.slice.html`. This is a serious
[usability bug](https://usability.yale.edu/web-accessibility/articles/links):
the square braces are much too small for anyone who doesn't have perfect
motor control using mouse or touch, provide an excessive number of tab stops
for anyone using keyboard, and no visual indication whatsoever that they're
separate links.
Now that slices of generic types are linked, it seems reasonable to err on
the side of less clutter and stop linking concrete slices to the slice page.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update minifier version to 0.2.1
This change and these changes come from an idea of `@camelid:` instead of creating a string, we just `write` the type into the file directly.
I don't think it'll have a big impact on perf but it's still a potential small improvement.
r? `@notriddle`
|
|
This commit adds a new unstable attribute, `#[doc(tuple_varadic)]`, that
shows a 1-tuple as `(T, ...)` instead of just `(T,)`, and links to a section
in the tuple primitive docs that talks about these.
|
|
|
|
More eslint checks
Here is the list of newly added eslint checks:
* [no-confusing-arrow](https://eslint.org/docs/rules/no-confusing-arrow)
* [no-div-regex](https://eslint.org/docs/rules/no-div-regex)
* [no-floating-decimal](https://eslint.org/docs/rules/no-floating-decimal)
* [no-implicit-globals](https://eslint.org/docs/rules/no-implicit-globals)
* [no-implied-eval](https://eslint.org/docs/rules/no-implied-eval)
* [no-label-var](https://eslint.org/docs/rules/no-label-var)
Since you already reviewed the previous ones:
r? `@Dylan-DPC`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add empty impl blocks if they have documentation
Fixes https://github.com/rust-lang/rust/issues/90866.
The update for the test script is needed to count the number of impl blocks we have with only the struct. To be noted that with https://github.com/rust-lang/rust/pull/89676 merged, it wouldn't be needed (I don't know what is the status of it btw. cc ```@Mark-Simulacrum).```
It looks like this:
cc ```@jyn514```
r? ```@camelid```
|
|
Hack: many traits and types in std are re-exported from core or alloc. In
general, rustdoc is capable of recognizing these implementations as being
on local types. However, in at least one case, rustdoc gets confused and
labels an implementation as being on a foreign type. To make sure that
confusion doesn't pass on to the reader, consider all implementations in
std, core, and alloc to be on local types.
|
|
Add more eslint checks
A new batch of eslint rules:
* [no-fallthrough](https://eslint.org/docs/rules/no-fallthrough)
* [no-invalid-regexp](https://eslint.org/docs/rules/no-invalid-regexp)
* [no-import-assign](https://eslint.org/docs/rules/no-import-assign)
* [no-self-compare](https://eslint.org/docs/rules/no-self-compare)
* [no-template-curly-in-string](https://eslint.org/docs/rules/no-template-curly-in-string)
* [block-scoped-var](https://eslint.org/docs/rules/block-scoped-var)
* [guard-for-in](https://eslint.org/docs/rules/guard-for-in)
* [no-alert](https://eslint.org/docs/rules/no-alert)
r? ``@notriddle``
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
rustdoc: Improve calculation of "Impls on Foreign Types"
The existing code to calculate whether an implementation was on a "Foreign Type" was duplicated across the sidebar generation and the page generation. It also came to the wrong conclusion for some cases where both the trait and the "for" type were re-exports.
This PR extracts the logic into a method of `Impl`, breaks it into a multi-line method so it can be commented, and adds a case for when the trait and the "for" type came from the same crate. This fixes some cases - like the platform-specific integer types (`__m256`, `__m128`, etc). But it doesn't fix all cases. See the screenshots below.
[Before](https://doc.rust-lang.org/nightly/std/clone/trait.Clone.html#foreign-impls):
<img src="https://user-images.githubusercontent.com/220205/171338226-59ce6daf-3d76-4bad-bc8d-72a8259a8f43.png" width=200>
[After](https://rustdoc.crud.net/jsha/implementation-is-on-local-type/std/clone/trait.Clone.html):
<img src="https://user-images.githubusercontent.com/220205/171338147-28308a65-1597-4223-be47-9550062404dd.png" width=200>
The remaining types (`CString`, `NulError`, etc) are all from the `alloc` crate, while the `Clone` trait is from the `core` crate. Since `CString` and `Clone` are both re-exported by `std`, they are logically local to each other, but I couldn't figure out a good way to detect that in this code. I figure this is still a good step forward.
Related: #97610
r? `@camelid`
|
|
|
|
Co-authored-by: Noah Lev <camelidcamel@gmail.com>
|
|
|
|
|
|
|
|
Improve settings theme display
This is a follow-up of #96958. In this PR, I changed how the theme radio buttons are displayed and improved their look as well.
It now looks like this:
You can test it [here](https://rustdoc.crud.net/imperio/improve-settings-theme-display/doc/foo/index.html).
r? `@jsha`
|
|
line number
|
|
|
