| Age | Commit message (Collapse) | Author | Lines |
|---|
|
There's no such thing as a big section header, so I don't know why the
name was used.
|
|
This way, most of the parsing code doesn't need to be designed to handle
it, since they should always be treated exactly the same anyhow.
|
|
This is already covered by the normal unexpected char path.
|
|
This restriction made sense back when spaces separated function
parameters, but now that they separate path components, there's
no real ambiguity any more.
Additionally, the Rust language allows it.
|
|
|
|
They're only used for HTML, so it makes more sense for them to live
their.
|
|
Rollup of 3 pull requests
Successful merges:
- #118322 (skip {tidy,compiletest,rustdoc-gui} based tests for `DocTests::Only`)
- #118325 (Fix Rustdoc search docs link)
- #118338 (Backticks fixes)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix Rustdoc search docs link
This link has been outdated since #112725 moved the search docs to their own page
|
|
r=notriddle
rustdoc: Remove space from fake-variadic fn ptr impls
before: `for fn (T₁, T₂, …, Tₙ) -> Ret`
after: `for fn(T₁, T₂, …, Tₙ) -> Ret`
I don't think we usually have spaces there, so it looks weird.
cc `@notriddle` since you added the space in https://github.com/rust-lang/rust/pull/98180 (or rather, added the feature with a space included).
|
|
|
|
before: `for fn (T₁, T₂, …, Tₙ) -> Ret`
after: `for fn(T₁, T₂, …, Tₙ) -> Ret`
|
|
rustdoc: replace `elemIsInParent` with `Node.contains`
According to [MDN], this function is compatible with:
* Chrome 16 and Edge 12
* Firefox 9
* Safari 1.1 and iOS Safari 1
These browsers are well within our [support matrix], which requires compatibility with Chrome 118, Firefox 115, Safari 17, and Edge 119.
[MDN]: https://developer.mozilla.org/en-US/docs/Web/API/Node/contains#browser_compatibility
[support matrix]: https://browsersl.ist/#q=last+2+Chrome+versions%2C+last+1+Firefox+version%2C+Firefox+ESR%2C+last+1+Safari+version%2C+last+1+iOS+version%2C+last+1+Edge+version%2C+last+1+UCAndroid+version
|
|
cleanup
|
|
`is_{some,ok}_and` for rustdoc
slightly more fluent-reading code
r? fmease
|
|
According to [MDN], this function is compatible with:
* Chrome 16 and Edge 12
* Firefox 9
* Safari 1.1 and iOS Safari 1
These browsers are well within our [support matrix], which requires
compatibility with Chrome 118, Firefox 115, Safari 17, and Edge 119.
[MDN]: https://developer.mozilla.org/en-US/docs/Web/API/Node/contains#browser_compatibility
[support matrix]: https://browsersl.ist/#q=last+2+Chrome+versions%2C+last+1+Firefox+version%2C+Firefox+ESR%2C+last+1+Safari+version%2C+last+1+iOS+version%2C+last+1+Edge+version%2C+last+1+UCAndroid+version
|
|
|
|
|
|
Replace `option.map(cond) == Some(true)` with `option.is_some_and(cond)`
Requested by `@fmease` in https://github.com/rust-lang/rust/pull/118226#pullrequestreview-1747432292.
There is also a much larger number of `option.map_or(false, cond)` that can be changed separately if someone wants.
r? fmease
|
|
Fixes #118242
|
|
|
|
|
|
Test for presence rather than absence
Remove redundant tests
Issues in those parts will likely be caught by other parts of the test suite.
|
|
|
|
The search sorting code already sorts by item type discriminant,
putting things with smaller discriminants first. There was
also a special case for sorting keywords and primitives earlier,
and this commit removes it by giving them lower discriminants.
The sorting code has another criteria where items with descriptions
appear earlier than items without, and that criteria has higher
priority than the item type. This shouldn't matter, though,
because primitives and keywords normally only appear in the
standard library, and it always gives them descriptions.
|
|
This computes the same result with less code by computing many of
the old checks at once:
* It won't enter the loop if clength > length, because then the
result of length - clength will be negative and the
loop conditional will fail.
* i + clength will never be greater than length, because it
starts out as i = length - clength, implying that i + clength
equals length, and it only goes down from there.
* The aborted variable is replaced with control flow.
|
|
|
|
This is significantly faster, because
- It allows the one-element fast path to kick in on multi-
element queries.
- It constructs intermediate data structures more lazily
than the old system did.
It's measurably faster than the old algo even without the fast path, but
that fast path still helps significantly.
|
|
|
|
Short queries, in addition to being common, are also the base
case for a lot of more complicated queries. We can avoid
most of the backtracking data structures, and use simple
recursive matching instead, by special casing them.
Profile output:
https://notriddle.com/rustdoc-html-demo-5/profile-3/index.html
|
|
This is a major source of expense on generic queries,
and this commit reduces them.
Profile output:
https://notriddle.com/rustdoc-html-demo-5/profile-2/index.html
|
|
Bootstrap bump
Bumps bootstrap compiler to just-released beta.
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday
|
|
|
|
This reduces code size while still matching the common case
for plain, concrete types.
|
|
make `LayoutError::Cycle` carry `ErrorGuaranteed`
Addresses a FIXME, and also I think it's wise for error variants to carry their `ErrorGuaranteed` -- makes it easier to use that `ErrorGuaranteed` for creating, e.g. `TyKind::Error` and other error kinds. Splitting out from #117703.
|
|
This didn't show up in our local tests, because the problem is actually
caused by docs.rs rewritten HTML (which relocates the classes that this
code looked for from the body tag to a child div).
Fixes #117290
|
|
|
|
|
|
rustdoc: stop preloading Source Serif 4 Bold
According to #91170, italic fonts are not preloaded because they're rarely used, but bold fonts are. This seems to be true of bold Source Code Pro and bold Fira Sans, but bold and italic Source Serif Pro seem to be equally heavily used.
This is, I assume, the result of using Fira Sans Bold and Source Code Bold headings, so you only get bold Serif text when the doc author uses strong `**` emphasis (or within certain kinds of tooltip, which shouldn't be preloaded because they only show up long after the page is loaded).
To check this, run these two commands in the browser console to measure how much they're used. The measurement is extremely rough, but it gets the idea across: the two styles are about equally popular.
// count bold elements
Array.prototype.slice.call(document.querySelectorAll("*")).filter(x => { const y = document.defaultView.getComputedStyle(x); return y.fontFamily.indexOf("Source Serif 4") !== -1 && y.fontWeight > 400 }).length
// count italic elements
Array.prototype.slice.call(document.querySelectorAll("*")).filter(x => { const y = document.defaultView.getComputedStyle(x); return y.fontFamily.indexOf("Source Serif 4") !== -1 && y.fontStyle == "italic" }).length
| URL | Bold | Italic |
|--------------|-----:|-------:|
| [std] | 2 | 9 |
| [Vec] | 8 | 89 |
| [regex] | 33 | 17 |
| [test_suite] | 0 | 0 |
[std]: https://doc.rust-lang.org/nightly/std/index.html
[Vec]: https://doc.rust-lang.org/nightly/std/vec/struct.Vec.html
[regex]: https://docs.rs/regex/1.9.5/regex/index.html
[test_suite]: https://docs.rs/test-suite/3.2.9/test_suite/
|
|
matthiaskrgr:baby_dont_clone_me_dont_clone_me_no_more, r=est31
clone less
|
|
`rustc_span` cleanups
Just some things I found while looking over this crate.
r? `@oli-obk`
|
|
|
|
|
|
Most notably, this commit changes the `pub use crate::*;` in that file
to `use crate::*;`. This requires a lot of `use` items in other crates
to be adjusted, because everything defined within `rustc_span::*` was
also available via `rustc_span::source_map::*`, which is bizarre.
The commit also removes `SourceMap::span_to_relative_line_string`, which
is unused.
|
|
rustdoc: Document lack of object safety on affected traits
Closes #85138
I saw the issue didn't have any recent activity, if there is another MR for it I missed it.
I want the issue to move forward so here is my proposition.
It takes some space just before the "Implementors" section and only if the trait is **not** object
safe since it is the only case where special care must be taken in some cases and this has the
benefit of avoiding generation of HTML in (I hope) the common case.
|
|
|
|
|
|
|
|
|
|
|
|
|
