about summary refs log tree commit diff
path: root/src/librustdoc
AgeCommit message (Collapse)AuthorLines
2022-06-16Move `finish` out of the `Encoder` trait.Nicholas Nethercote-1/+1
This simplifies things, but requires making `CacheEncoder` non-generic. (This was previously merged as commit 4 in #94732 and then was reverted in #97905 because it caused a perf regression.)
2022-06-16Auto merge of #98108 - SpriteOvO:doc_auto_cfg-feature-rmv-fix, ↵bors-7/+14
r=notriddle,GuillaumeGomez Rustdoc: Fix stab disappearing and exclude cfg "doc" and "doctest" Fixes #98065 Context: https://github.com/rust-lang/rust/issues/43781#issuecomment-1154226733 r? `@GuillaumeGomez`
2022-06-16Rollup merge of #98092 - GuillaumeGomez:fix-sidebar-items-expand-collapse, ↵Yuki Okushi-3/+3
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: ![Screenshot from 2022-06-14 11-21-58](https://user-images.githubusercontent.com/3050060/173543346-af056928-e921-458f-b918-60f6fd0ecbde.png) ). This PR fixes it and adds a GUI test to prevent another regression. r? ```@notriddle```
2022-06-16Rollup merge of #98053 - GuillaumeGomez:fix-generic-impl-json-ice, r=notriddleYuki Okushi-10/+43
Fix generic impl rustdoc json output Fixes #97986. The problem in case of generic trait impl is that the trait's items are the same for all the types afterward. But since they're the same, it's safe for rustdoc-json to just ignore them. A little representation of what's going on: ```rust trait T { fn f(); // <- defid 0 } impl<Y> T for Y { fn f() {} // <- defid 1 } struct S; // <- defid 1 (since it matches `impl<Y> T for Y` ``` cc ```@Urgau``` r? ```@CraftSpider```
2022-06-16Exclude cfg "doc" and "doctest" from feature `doc_auto_cfg`Sprite-1/+4
2022-06-16Fix `cfg(not)` and `cfg(all)` causing Rustdoc stab to disappearSprite-6/+10
2022-06-15Rollup merge of #98083 - nnethercote:rename-Encoder, r=bjorn3Yuki Okushi-2/+2
Rename rustc_serialize::opaque::Encoder as MemEncoder. This avoids the name clash with `rustc_serialize::Encoder` (a trait), and allows lots qualifiers to be removed and imports to be simplified (e.g. fewer `as` imports). (This was previously merged as commit 5 in #94732 and then was reverted in #97905 because of a perf regression caused by commit 4 in #94732.) r? ```@bjorn3```
2022-06-14Make ResolverAstLowering a struct.Camille GILLOT-2/+0
2022-06-14rustdoc: change "variadic tuple" notation to look less like real syntaxMichael Howell-1/+1
2022-06-14rustdoc: remove tuple link on round bracesMichael Howell-10/+34
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.
2022-06-14address reviewb-naber-9/+10
2022-06-14implement valtrees as the type-system representation for constant valuesb-naber-7/+6
2022-06-14Fix expand/collapse on source viewer sidebar foldersGuillaume Gomez-3/+3
2022-06-14Rollup merge of #98069 - notriddle:notriddle/square-brackets, r=jshaDylan DPC-27/+2
rustdoc: remove link on slice brackets This is #91778, take two. Fixes #91173 The reason I'm reevaluating this change is #97668, which makes fully-generic slices link to the slice docs page. This fixes some downsides in the original PR, where `Box<[T]>`, for example, was not linked to the primitive.slice.html page. In this PR, the `[T]` inside is still a link. The other major reason for wanting to reevaluate this is the changed color scheme. When this feature was first introduced in rustdoc, primitives were a different color from structs and enums. This way, eagle-eyed users could figure out that the square brackets were separate links from the structs inside. Now, all types have the same color, so a significant fraction of users won't even know the links are there unless they pay close attention to the status bar or use an accessibility tool that lists all links on the page.
2022-06-14Rename rustc_serialize::opaque::Encoder as MemEncoder.Nicholas Nethercote-2/+2
This avoids the name clash with `rustc_serialize::Encoder` (a trait), and allows lots qualifiers to be removed and imports to be simplified (e.g. fewer `as` imports). (This was previously merged as commit 5 in #94732 and then was reverted in #97905 because of a perf regression caused by commit 4 in #94732.)
2022-06-14Rename the `ConstS::val` field as `kind`.Nicholas Nethercote-2/+2
And likewise for the `Const::val` method. Because its type is called `ConstKind`. Also `val` is a confusing name because `ConstKind` is an enum with seven variants, one of which is called `Value`. Also, this gives consistency with `TyS` and `PredicateS` which have `kind` fields. The commit also renames a few `Const` variables from `val` to `c`, to avoid confusion with the `ConstKind::Value` variant.
2022-06-13rustdoc: remove link on slice bracketsMichael Howell-27/+2
Since #97668 was merged, the slice::get function now looks like this: ![image](https://user-images.githubusercontent.com/1593513/173430685-1dd2b275-2439-4392-b7d4-96bcb355a377.png) 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: ![image](https://user-images.githubusercontent.com/1593513/173430968-7eed1aec-b688-4f84-a492-9210aff0037a.png) 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.
2022-06-13Ignore impl items because they can be duplicated in case of generic implGuillaume Gomez-10/+43
2022-06-13remove unnecessary `to_string` and `String::new`Takayuki Maeda-1/+1
2022-06-11Add test case for #trait-implementations-1 linkMichael Howell-0/+2
2022-06-11Fix incorrectly spelled "variadic"Michael Howell-4/+4
2022-06-11Add eslint rule "no-script-url"Guillaume Gomez-0/+1
2022-06-11Add eslint rule "no-return-assign"Guillaume Gomez-0/+1
2022-06-11Add eslint rule "no-multi-assign"Guillaume Gomez-0/+1
2022-06-11Add eslint rule "no-mixed-operator"Guillaume Gomez-0/+1
2022-06-11Add eslint rule "no-lonely-if"Guillaume Gomez-0/+1
2022-06-11Auto merge of #97905 - nnethercote:revert-infallible-encoder, r=bjorn3bors-3/+3
Revert part of #94372 to improve performance #94732 was supposed to give small but widespread performance improvements, as judged from three per-merge performance runs. But the performance run that occurred after merging included a roughly equal number of improvements and regressions, for unclear reasons. This PR is for a test run reverting those changes, to see what happens. r? `@ghost`
2022-06-10Revert dc08bc51f2c58a0f5f815a07f9bb3d671153b5a1.Nicholas Nethercote-1/+1
2022-06-10Revert b983e42936feab29f6333e9835913afc6b4a394e.Nicholas Nethercote-2/+2
2022-06-09Auto merge of #97772 - GuillaumeGomez:minifier-update, r=notriddlebors-6/+9
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`
2022-06-08rustdoc: fixed messed-up rustdoc auto trait implsMichael Howell-4/+4
Before: impl<T, U> UnwindSafe for (T, ...) where T: UnwindSafe, U: UnwindSafe, After: impl<T> UnwindSafe for (T, ...) where T: UnwindSafe,
2022-06-08rustdoc: show tuple impls as `impl Trait for (T, ...)`Michael Howell-6/+33
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.
2022-06-08Auto merge of #94732 - nnethercote:infallible-encoder, r=bjorn3bors-4/+4
Make `Encodable` and `Encoder` infallible. A follow-up to #93066. r? `@ghost`
2022-06-08Rename `rustc_serialize::opaque::Encoder` as `MemEncoder`.Nicholas Nethercote-2/+2
This avoids the name clash with `rustc_serialize::Encoder` (a trait), and allows lots qualifiers to be removed and imports to be simplified (e.g. fewer `as` imports).
2022-06-08Folding revamp.Nicholas Nethercote-1/+1
This commit makes type folding more like the way chalk does it. Currently, `TypeFoldable` has `fold_with` and `super_fold_with` methods. - `fold_with` is the standard entry point, and defaults to calling `super_fold_with`. - `super_fold_with` does the actual work of traversing a type. - For a few types of interest (`Ty`, `Region`, etc.) `fold_with` instead calls into a `TypeFolder`, which can then call back into `super_fold_with`. With the new approach, `TypeFoldable` has `fold_with` and `TypeSuperFoldable` has `super_fold_with`. - `fold_with` is still the standard entry point, *and* it does the actual work of traversing a type, for all types except types of interest. - `super_fold_with` is only implemented for the types of interest. Benefits of the new model. - I find it easier to understand. The distinction between types of interest and other types is clearer, and `super_fold_with` doesn't exist for most types. - With the current model is easy to get confused and implement a `super_fold_with` method that should be left defaulted. (Some of the precursor commits fixed such cases.) - With the current model it's easy to call `super_fold_with` within `TypeFolder` impls where `fold_with` should be called. The new approach makes this mistake impossible, and this commit fixes a number of such cases. - It's potentially faster, because it avoids the `fold_with` -> `super_fold_with` call in all cases except types of interest. A lot of the time the compile would inline those away, but not necessarily always.
2022-06-08Move `finish` out of the `Encoder` trait.Nicholas Nethercote-1/+1
This simplifies things, but requires making `CacheEncoder` non-generic.
2022-06-08Use delayed error handling for `Encodable` and `Encoder` infallible.Nicholas Nethercote-3/+3
There are two impls of the `Encoder` trait: `opaque::Encoder` and `opaque::FileEncoder`. The former encodes into memory and is infallible, the latter writes to file and is fallible. Currently, standard `Result`/`?`/`unwrap` error handling is used, but this is a bit verbose and has non-trivial cost, which is annoying given how rare failures are (especially in the infallible `opaque::Encoder` case). This commit changes how `Encoder` fallibility is handled. All the `emit_*` methods are now infallible. `opaque::Encoder` requires no great changes for this. `opaque::FileEncoder` now implements a delayed error handling strategy. If a failure occurs, it records this via the `res` field, and all subsequent encoding operations are skipped if `res` indicates an error has occurred. Once encoding is complete, the new `finish` method is called, which returns a `Result`. In other words, there is now a single `Result`-producing method instead of many of them. This has very little effect on how any file errors are reported if `opaque::FileEncoder` has any failures. Much of this commit is boring mechanical changes, removing `Result` return values and `?` or `unwrap` from expressions. The more interesting parts are as follows. - serialize.rs: The `Encoder` trait gains an `Ok` associated type. The `into_inner` method is changed into `finish`, which returns `Result<Vec<u8>, !>`. - opaque.rs: The `FileEncoder` adopts the delayed error handling strategy. Its `Ok` type is a `usize`, returning the number of bytes written, replacing previous uses of `FileEncoder::position`. - Various methods that take an encoder now consume it, rather than being passed a mutable reference, e.g. `serialize_query_result_cache`.
2022-06-07Update minifier version to 0.2.1Guillaume Gomez-6/+9
2022-06-07Auto merge of #95565 - jackh726:remove-borrowck-mode, r=nikomatsakisbors-1/+1
Remove migrate borrowck mode Closes #58781 Closes #43234 # Stabilization proposal This PR proposes the stabilization of `#![feature(nll)]` and the removal of `-Z borrowck`. Current borrow checking behavior of item bodies is currently done by first infering regions *lexically* and reporting any errors during HIR type checking. If there *are* any errors, then MIR borrowck (NLL) never occurs. If there *aren't* any errors, then MIR borrowck happens and any errors there would be reported. This PR removes the lexical region check of item bodies entirely and only uses MIR borrowck. Because MIR borrowck could never *not* be run for a compiled program, this should not break any programs. It does, however, change diagnostics significantly and allows a slightly larger set of programs to compile. Tracking issue: #43234 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll.md Version: 1.63 (2022-06-30 => beta, 2022-08-11 => stable). ## Motivation Over time, the Rust borrow checker has become "smarter" and thus allowed more programs to compile. There have been three different implementations: AST borrowck, MIR borrowck, and polonius (well, in progress). Additionally, there is the "lexical region resolver", which (roughly) solves the constraints generated through HIR typeck. It is not a full borrow checker, but does emit some errors. The AST borrowck was the original implementation of the borrow checker and was part of the initially stabilized Rust 1.0. In mid 2017, work began to implement the current MIR borrow checker and that effort ompleted by the end of 2017, for the most part. During 2018, efforts were made to migrate away from the AST borrow checker to the MIR borrow checker - eventually culminating into "migrate" mode - where HIR typeck with lexical region resolving following by MIR borrow checking - being active by default in the 2018 edition. In early 2019, migrate mode was turned on by default in the 2015 edition as well, but with MIR borrowck errors emitted as warnings. By late 2019, these warnings were upgraded to full errors. This was followed by the complete removal of the AST borrow checker. In the period since, various errors emitted by the MIR borrow checker have been improved to the point that they are mostly the same or better than those emitted by the lexical region resolver. While there do remain some degradations in errors (tracked under the [NLL-diagnostics tag](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics), those are sufficiently small and rare enough that increased flexibility of MIR borrow check-only is now a worthwhile tradeoff. ## What is stabilized As said previously, this does not fundamentally change the landscape of accepted programs. However, there are a [few](https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-fixed-by-NLL) cases where programs can compile under `feature(nll)`, but not otherwise. There are two notable patterns that are "fixed" by this stabilization. First, the `scoped_threads` feature, which is a continutation of a pre-1.0 API, can sometimes emit a [weird lifetime error](https://github.com/rust-lang/rust/issues/95527) without NLL. Second, actually seen in the standard library. In the `Extend` impl for `HashMap`, there is an implied bound of `K: 'a` that is available with NLL on but not without - this is utilized in the impl. As mentioned before, there are a large number of diagnostic differences. Most of them are better, but some are worse. None are serious or happen often enough to need to block this PR. The biggest change is the loss of error code for a number of lifetime errors in favor of more general "lifetime may not live long enough" error. While this may *seem* bad, the former error codes were just attempts to somewhat-arbitrarily bin together lifetime errors of the same type; however, on paper, they end up being roughly the same with roughly the same kinds of solutions. ## What isn't stabilized This PR does not completely remove the lexical region resolver. In the future, it may be possible to remove that (while still keeping HIR typeck) or to remove it together with HIR typeck. ## Tests Many test outputs get updated by this PR. However, there are number of tests specifically geared towards NLL under `src/test/ui/nll` ## History * On 2017-07-14, [tracking issue opened](https://github.com/rust-lang/rust/issues/43234) * On 2017-07-20, [initial empty MIR pass added](https://github.com/rust-lang/rust/pull/43271) * On 2017-08-29, [RFC opened](https://github.com/rust-lang/rfcs/pull/2094) * On 2017-11-16, [Integrate MIR type-checker with NLL](https://github.com/rust-lang/rust/pull/45825) * On 2017-12-20, [NLL feature complete](https://github.com/rust-lang/rust/pull/46862) * On 2018-07-07, [Don't run AST borrowck on mir mode](https://github.com/rust-lang/rust/pull/52083) * On 2018-07-27, [Add migrate mode](https://github.com/rust-lang/rust/pull/52681) * On 2019-04-22, [Enable migrate mode on 2015 edition](https://github.com/rust-lang/rust/pull/59114) * On 2019-08-26, [Don't downgrade errors on 2015 edition](https://github.com/rust-lang/rust/pull/64221) * On 2019-08-27, [Remove AST borrowck](https://github.com/rust-lang/rust/pull/64790)
2022-06-07Rollup merge of #97792 - GuillaumeGomez:eslint-checks, r=Dylan-DPCMatthias Krüger-1/+7
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`
2022-06-06Add "no-label-var" eslint checkGuillaume Gomez-0/+1
2022-06-06Add "no-implied-eval" eslint checkGuillaume Gomez-0/+1
2022-06-06Add "no-implicit-globals" eslint checkGuillaume Gomez-0/+1
2022-06-06Add "no-floating-decimal" eslint checkGuillaume Gomez-0/+1
2022-06-06Add "no-div-regex" eslint checkGuillaume Gomez-0/+1
2022-06-06Add "no-confusing-arrow" eslint checkGuillaume Gomez-1/+2
2022-06-06Rollup merge of #90905 - GuillaumeGomez:empty-impl-blocks, r=jshaMatthias Krüger-3/+17
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: ![Screenshot from 2021-11-14 16-51-28](https://user-images.githubusercontent.com/3050060/141689100-e57123c0-bf50-4c42-adf5-d991e169a0e4.png) cc ```@jyn514``` r? ```@camelid```
2022-06-04Don't generate "Impls on Foreign Types" for stdJacob Hoffman-Andrews-6/+18
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.
2022-06-03Fully stabilize NLLJack Huey-1/+1
2022-06-03Rollup merge of #97681 - GuillaumeGomez:more-eslint, r=Dylan-DPCDylan DPC-0/+8
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``