| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Do not emit `missing_doc_code_examples` rustdoc lint on module and a few other items
It doesn't make sense to expect modules to have code examples. Same goes for:
* Trait aliases
* Foreign items
* Associated types and constants
Should make the use of this lint a bit nicer.
r? ``@notriddle``
|
|
Remove Node::ArrayLenInfer
|
|
[rustdoc] Change impl items indent
Fixes https://github.com/rust-lang/rust/issues/131704.
| before | after |
|-|-|
|  |  |
Can be tested [here](https://rustdoc.crud.net/imperio/impl-items-indent/bar/struct.Bar.html).
r? `@notriddle`
|
|
other items
|
|
|
|
|
|
Fix `Result` and `Option` not getting a jump to def link generated
It was just because we didn't store the "span" in the `PreludeTy` variant.
r? ``@notriddle``
|
|
Remove dead code stemming from the old effects desugaring (II)
Follow-up to #132374.
r? project-const-traits
|
|
|
|
|
|
|
|
|
|
continue `ParamEnv` to `TypingEnv` transition
cc #132279
r? `@compiler-errors`
|
|
r=compiler-errors
Remove `TokenKind::InvalidPrefix`
It's not needed. Best reviewed one commit at a time.
r? `@estebank`
|
|
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #131081 (Use `ConstArgKind::Path` for all single-segment paths, not just params under `min_generic_const_args`)
- #132577 (Report the `unexpected_cfgs` lint in external macros)
- #133023 (Merge `-Zhir-stats` into `-Zinput-stats`)
- #133200 (ignore an occasionally-failing test in Miri)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
It was added in #123752 to handle some cases involving emoji, but it
isn't necessary because it's always treated the same as
`TokenKind::InvalidIdent`. This commit removes it, which makes things a
little simpler.
|
|
Co-authored-by: Boxy UwU <rust@boxyuwu.dev>
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
|
|
rustdoc-search: use smart binary search in bitmaps
Addresses a comment from [jsha's benchmarking], where the `contains` function showed up in the profiler. This commit pulls it from about 5% of the runtime to about 0.5%.
Before: https://share.firefox.dev/3ANVjon
After: https://share.firefox.dev/3OeM3gk
[jsha's benchmarking]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/search.20profiling/near/481868761
|
|
[rustdoc] Fix items with generics not having their jump to def link generated
Because the span originally included the generics, during the highlighting, it was not retrieved and therefore its jump to def link was not generated.
r? ``@notriddle``
|
|
|
|
Addresses a comment from [jsha's benchmarking], where the `contains`
function showed up in the profiler. This commit pulls it from about
5% of the runtime to about 0.5%.
[jsha's benchmarking]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/search.20profiling/near/481868761
|
|
|
|
|
|
the behavior of the type system not only depends on the current
assumptions, but also the currentnphase of the compiler. This is
mostly necessary as we need to decide whether and how to reveal
opaque types. We track this via the `TypingMode`.
|
|
fixes https://github.com/rust-lang/rust/issues/129707
this can be used to show all items in a module,
or all associated items for a type.
currently sufferes slightly due to case insensitivity,
so `Option::` will also show items in the `option::` module.
it disables the checking of the last path element,
otherwise only items with short names will be shown
|
|
Rollup of 4 pull requests
Successful merges:
- #128197 (Skip locking span interner for some syntax context checks)
- #133040 ([rustdoc] Fix handling of footnote reference in footnote definition)
- #133043 (rustdoc-search: case-sensitive only when capitals are used)
- #133046 (Clippy subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc-search: case-sensitive only when capitals are used
This is the "smartcase" behavior, described by vim and dtolnay.
Fixes https://github.com/rust-lang/rust/issues/133017
|
|
This is the "smartcase" behavior, described by vim and dtolnay.
|
|
|
|
rustdoc: use a trie for name-based search
Potentially https://github.com/rust-lang/rust/issues/131156 — need to try reproducing the problem with `windows`
Preview and profiler results
----------------------------
Here's some quick profiling in Firefox done on the rust compiler docs:
- Before: https://share.firefox.dev/3UPm3M8
- After: https://share.firefox.dev/40LXvYb
Here's the results for the node.js profiler:
- https://notriddle.com/rustdoc-html-demo-15/trie-perf/index.html
Here's a copy that you can use to try it out. Compare it with [the nightly]. Try typing `typecheckercontext` one character at a time, slowly.
- https://notriddle.com/rustdoc-html-demo-15/compiler-doc-trie/index.html
[the nightly]: https://doc.rust-lang.org/nightly/nightly-rustc/
The fuzzy match algo is based on [Fast String Correction with Levenshtein-Automata] and the corresponding implementation code in [moman] and [Lucene]; the bit-packing representation comes from Lucene, but the actual matcher is more based on `fsc.py`. As suggested in the paper, a trie is used to represent the FSA dictionary.
The same trie is used for prefix matching. Substring matching is done with a side table of three-character[^1] windows that point into the trie.
[Fast String Correction with Levenshtein-Automata]: https://github.com/tpn/pdfs/blob/master/Fast%20String%20Correction%20with%20Levenshtein-Automata%20(2002)%20(10.1.1.16.652).pdf
[Lucene]: https://fossies.org/linux/lucene/lucene/core/src/java/org/apache/lucene/util/automaton/Lev1TParametricDescription.java
[moman]: https://gitlab.com/notriddle/moman-rustdoc
User-visible changes
--------------------
I don't expect anybody to notice anything, but it does cause two changes:
- Substring matches, in the middle of a name, only apply if there's three or more characters in the search query.
- Levenshtein distance limit now maxes out at two. In the old version, the limit was w/3, so you could get looser matches for queries with 9 or more characters[^1] in them.
- It uses more RAM.
- It's faster (assuming you don't swap thrash).
[^1]: technically utf-16 code units
|
|
|
|
|
|
[rustdoc] Fix duplicated footnote IDs
Fixes https://github.com/rust-lang/rust/issues/131901.
Footnote IDs were increased locally (ie, on the docblock) and not globally (ie, on the whole item page).
cc `@aDotInTheVoid`
r? `@notriddle`
|
|
rustdoc: Treat declarative macros more like other item kinds
Apparently at some time in the past we were unable to generate an href for the module path inside the visibility of decl macros 2.0 (`pub(in ...)`). As a result of this, a whole separate function was introduced specifically for printing the visibility of decl macros that didn't attempt to generate any links. The description of PR https://github.com/rust-lang/rust/pull/84074 states:
> This fixes the overly-complex invariant mentioned in https://github.com/rust-lang/rust/pull/83237#issuecomment-815346570, where the macro source can't have any links in it only because the cache hasn't been populated yet.
I can no longer reproduce the original issue. Reusing the existing visibility rendering logic *seems* to work just fine (I couldn't come up with any counterexamples, though I invite you to prove me wrong).
* Fixes #83000
* Fixes the visibility showing up "twice" in rustdoc-JSON output: Once as the `visibility` field, once baked into the source[^1]
* Fixes `#[doc(hidden)]` not getting rendered on doc(hidden) decl macros 2.0 under `--document-hiden-items` (for decl macros 1.2 the issue remains; I will address this separately when fixing #132304).
---
<details><summary>Outdated Section</summary>
NOTE: The current version of this PR is committing a UI crime, I'd like to receive feedback on that. Maybe you have a satisfactory solution for how to remedy it. Namely, as you know we have two different ways of / modes for highlighting code with color:
1. Only highlighting links / item paths and avoiding to highlight tokens by kind like keywords (to reduce visual noise and maybe also artifact size). Used for item declarations(\*).
2. Highlighting tokens by kind. Used for code blocks written by the user.
(\*): With the notable exception being macro declarations! Well, since this PR reuses the same function for rendering the item visibility (which only makes sense), we have a clash of modes: We now use both ways of highlighting code for decl macros: №1 for the visibility, №2 for the rest. This awkward. See for yourself:
* On master: 
* On this branch: 
</details>
Furthermore, we now no longer syntax-highlight declarative macros (be it `macro_rules!` or `macro`) since that was inconsistent with the way we render all other item kinds. See (collapsed) *Outdated Section* above. See also https://github.com/rust-lang/rust/pull/132302#discussion_r1821310783.
| On master | On this branch |
|---|---|
|  |  |
[^1]: E.g., `"visibility":{"restricted":{"parent":1,"path":"::a"}},/*OMITTED*/,"inner":{"macro":"pub(in a) macro by_example_vis_named($foo:expr) {\n ...\n}"}`
|
|
Preview and profiler results
----------------------------
Here's some quick profiling in Firefox done on the rust compiler docs:
- Before: https://share.firefox.dev/3UPm3M8
- After: https://share.firefox.dev/40LXvYb
Here's the results for the node.js profiler:
- https://notriddle.com/rustdoc-html-demo-15/trie-perf/index.html
Here's a copy that you can use to try it out. Compare it with [the nightly].
Try typing `typecheckercontext` one character at a time, slowly.
- https://notriddle.com/rustdoc-html-demo-15/compiler-doc-trie/index.html
[the nightly]: https://doc.rust-lang.org/nightly/nightly-rustc/
The fuzzy match algo is based on [Fast String Correction with
Levenshtein-Automata] and the corresponding implementation code in [moman]
and [Lucene]; the bit-packing representation comes from Lucene, but the
actual matcher is more based on `fsc.py`. As suggested in the paper, a
trie is used to represent the FSA dictionary.
The same trie is used for prefix matching. Substring matching is done with a
side table of three-character[^1] windows that point into the trie.
[Fast String Correction with Levenshtein-Automata]: https://github.com/tpn/pdfs/blob/master/Fast%20String%20Correction%20with%20Levenshtein-Automata%20(2002)%20(10.1.1.16.652).pdf
[Lucene]: https://fossies.org/linux/lucene/lucene/core/src/java/org/apache/lucene/util/automaton/Lev1TParametricDescription.java
[moman]: https://gitlab.com/notriddle/moman-rustdoc
User-visible changes
--------------------
I don't expect anybody to notice anything, but it does cause two changes:
- Substring matches, in the middle of a name, only apply if there's three
or more characters in the search query.
- Levenshtein distance limit now maxes out at two. In the old version,
the limit was w/3, so you could get looser matches for queries with
9 or more characters[^1] in them.
[^1]: technically utf-16 code units
|
|
|
|
|
|
|
|
[perf] rustdoc: Perform less work when cleaning middle::ty parenthesized generic args
CC #132697. I presume the perf regression it caused (if real) boils down to query invocation overhead, namely of `def_kind` & `trait_def` as we don't seem to be decoding more often from the crate metadata.
I won't try the obvious and reduce the amount of query calls by threading information via params as that would render the code awkward.
So instead I'm simply trying to attack some low-hanging fruits in the vicinity.
---
Previously, we would `clean_middle_generic_args` *unconditionally* inside `clean_middle_generic_args_with_constraints` even though we didn't actually use its result for parenthesized generic args (`Trait(...) -> ...`).
Now, we only call `clean_middle_generic_args` when necessary. Lastly, I've simplified `clean_middle_generic_args_with_constraints`.
---
r? ghost
|
|
Rollup of 7 pull requests
Successful merges:
- #131831 (extend the "if-unchanged" logic for compiler builds)
- #132541 (Proper support for cross-crate recursive const stability checks)
- #132657 (AIX: add run-make support)
- #132901 (Warn about invalid `mir-enable-passes` pass names)
- #132923 (Triagebot: Consolidate the T-compiler ad hoc assignment groups)
- #132938 (Make precise capturing suggestion machine-applicable only if it has no APITs)
- #132947 (clarify `must_produce_diag` ICE for debugging)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Proper support for cross-crate recursive const stability checks
~~Stacked on top of https://github.com/rust-lang/rust/pull/132492; only the last three commits are new.~~
In a crate without `staged_api` but with `-Zforce-unstable-if-unmarked`, we now subject all functions marked with `#[rustc_const_stable_indirect]` to recursive const stability checks. We require an opt-in so that by default, a crate can be built with `-Zforce-unstable-if-unmarked` and use nightly features as usual. This property is recorded in the crate metadata so when a `staged_api` crate calls such a function, it sees the `#[rustc_const_stable_indirect]` and allows it to be exposed on stable. This, finally, will let us expose `const fn` from hashbrown on stable.
The second commit makes const stability more like regular stability: via `check_missing_const_stability`, we ensure that all publicly reachable functions have a const stability attribute -- both in `staged_api` crates and `-Zforce-unstable-if-unmarked` crates. To achieve this, we move around the stability computation so that const stability is computed after regular stability is done. This lets us access the final result of the regular stability computation, which we use so that `const fn` can inherit the regular stability (but only if that is "unstable"). Fortunately, this lets us get rid of an `Option` in `ConstStability`.
This is the last PR that I have planned in this series.
r? `@compiler-errors`
|
|
|
|
Delete the `cfg(not(parallel))` serial compiler
Since it's inception a long time ago, the parallel compiler and its cfgs have been a maintenance burden. This was a necessary evil the allow iteration while not degrading performance because of synchronization overhead.
But this time is over. Thanks to the amazing work by the parallel working group (and the dyn sync crimes), the parallel compiler has now been fast enough to be shipped by default in nightly for quite a while now.
Stable and beta have still been on the serial compiler, because they can't use `-Zthreads` anyways.
But this is quite suboptimal:
- the maintenance burden still sucks
- we're not testing the serial compiler in nightly
Because of these reasons, it's time to end it. The serial compiler has served us well in the years since it was split from the parallel one, but it's over now.
Let the knight slay one head of the two-headed dragon!
#113349
Note that the default is still 1 thread, as more than 1 thread is still fairly broken.
cc `@onur-ozkan` to see if i did the bootstrap field removal correctly, `@SparrowLii` on the sync parts
|
|
Since it's inception a long time ago, the parallel compiler and its cfgs
have been a maintenance burden. This was a necessary evil the allow
iteration while not degrading performance because of synchronization
overhead.
But this time is over. Thanks to the amazing work by the parallel
working group (and the dyn sync crimes), the parallel compiler has now
been fast enough to be shipped by default in nightly for quite a while
now.
Stable and beta have still been on the serial compiler, because they
can't use `-Zthreads` anyways.
But this is quite suboptimal:
- the maintenance burden still sucks
- we're not testing the serial compiler in nightly
Because of these reasons, it's time to end it. The serial compiler has
served us well in the years since it was split from the parallel one,
but it's over now.
Let the knight slay one head of the two-headed dragon!
|
|
|
|
rustdoc-search: simplify rules for generics and type params
**Heads up!**: This PR is a follow-up that depends on #124544. It adds 12dc24f46007f82b93ed85614347a42d47580afa, a change to the filtering behavior, and 9900ea48b566656fb12b5fcbd0a1b20aaa96e5ca, a minor ranking tweak.
Part of https://github.com/rust-lang/rust-project-goals/issues/112
This PR overturns https://github.com/rust-lang/rust/pull/109802
## Preview
* no results: [`Box<[A]> -> Vec<B>`](http://notriddle.com/rustdoc-html-demo-12/search-sem-3/std/index.html?search=Box%3C%5BA%5D%3E%20-%3E%20Vec%3CB%3E)
* results: [`Box<[A]> -> Vec<A>`](http://notriddle.com/rustdoc-html-demo-12/search-sem-3/std/index.html?search=Box%3C%5BA%5D%3E%20-%3E%20Vec%3CA%3E)
* [`T -> U`](http://notriddle.com/rustdoc-html-demo-12/search-sem-3/std/index.html?search=T%20-%3E%20U)
* [`Cx -> TyCtxt`](http://notriddle.com/rustdoc-html-demo-12/search-sem-3-compiler/rustdoc/index.html?search=Cx%20-%3E%20TyCtxt)
## Description
This commit is a response to feedback on the displayed type signatures results, by making generics act stricter.
- Order within generics is significant. This means `Vec<Allocator>` now matches only with a true vector of allocators, instead of matching the second type param. It also makes unboxing within generics stricter, so `Result<A, B>` only matches if `B` is in the error type and `A` is in the success type. The top level of the function search is unaffected.
- Generics are only "unboxed" if a type is explicitly opted into it. References and tuples are hardcoded to allow unboxing, and Box, Rc, Arc, Option, Result, and Future are opted in with an unstable attribute. Search result unboxing is the process that allows you to search for `i32 -> str` and get back a function with the type signature `&Future<i32> -> Box<str>`.
- Instead of ranking by set overlap, it ranks by the number of items in the type signature. This makes it easier to find single type signatures like transmute.
## Find the discussion on
* <https://rust-lang.zulipchat.com/#narrow/stream/393423-t-rustdoc.2Fmeetings/topic/meeting.202024-07-08/near/449965149>
* <https://github.com/rust-lang/rust/pull/124544#issuecomment-2204272265>
* <https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/deciding.20on.20semantics.20of.20generics.20in.20rustdoc.20search>
|
|
Add Unicode block-drawing compiler output support
Add nightly-only theming support to rustc output using Unicode box
drawing characters instead of ASCII-art to draw the terminal UI.
In order to enable, the flags `-Zunstable-options=yes --error-format=human-unicode` must be passed in.
After:
```
error: foo
╭▸ test.rs:3:3
│
3 │ X0 Y0 Z0
│ ┌───╿──│──┘
│ ┌│───│──┘
│ ┏││━━━┙
│ ┃││
4 │ ┃││ X1 Y1 Z1
5 │ ┃││ X2 Y2 Z2
│ ┃│└────╿──│──┘ `Z` label
│ ┃└─────│──┤
│ ┗━━━━━━┥ `Y` is a good letter too
│ `X` is a good letter
╰╴
note: bar
╭▸ test.rs:4:3
│
4 │ ┏ X1 Y1 Z1
5 │ ┃ X2 Y2 Z2
6 │ ┃ X3 Y3 Z3
│ ┗━━━━━━━━━━┛
├ note: bar
╰ note: baz
note: qux
╭▸ test.rs:4:3
│
4 │ X1 Y1 Z1
╰╴ ━━━━━━━━
```
Before:
```
error: foo
--> test.rs:3:3
|
3 | X0 Y0 Z0
| ___^__-__-
| |___|__|
| ||___|
| |||
4 | ||| X1 Y1 Z1
5 | ||| X2 Y2 Z2
| |||____^__-__- `Z` label
| ||_____|__|
| |______| `Y` is a good letter too
| `X` is a good letter
|
note: bar
--> test.rs:4:3
|
4 | / X1 Y1 Z1
5 | | X2 Y2 Z2
6 | | X3 Y3 Z3
| |__________^
= note: bar
= note: baz
note: qux
--> test.rs:4:3
|
4 | X1 Y1 Z1
| ^^^^^^^^
```
After:
Before:
|
