Rollup of 6 pull requests #84008
Merged
Rollup of 6 pull requests #84008
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ks using HTML-syntax.
…ual consistency.
…the markdown link definition names being case insensitive.
Co-authored-by: Takayuki Nakata <f.seasons017@gmail.com>
Update changelog for 1.52 I've underestimated the work that goes into this a bit, but it just shows that a lot has happened again in Clippy in 1.52 🙃. [Rendered](https://github.com/xFrednet/rust-clippy/blob/changelog-1-52/CHANGELOG.md) --- changelog: none
Fix bad suggestion when a reborrow might be required Fix bad suggestion when the value being sliced is a macro call Don't lint inside of a macro due to the previous context sensitive changes
Improve `redundant_slicing` fixes: rust-lang#6968 changelog: Fix `redundant_slicing` suggestion when a reborrow might be required or when the value is from a macro call
Add MSRV options to `unnested_or_patterns` changelog: [`unnested_or_patterns`] can now be configured with the `msrv` config/attribute. Fixes rust-lang#6953
Resolves rust-lang#78302 Update peekable.rs Update library/core/src/iter/traits/iterator.rs Co-authored-by: Ashley Mannix <kodraus@hey.com>
When the character next to `{}` is "shifted" (when mapping a byte index
in the format string to span) we should avoid shifting the span end
index, so first map the index of `}` to span, then bump the span,
instead of first mapping the next byte index to a span (which causes
bumping the end span too much).
Regression test added.
Fixes rust-lang#83344
Check the return type of `len`. Only integral types, or an `Option` or `Result` wrapping one. Ensure the return type of `is_empty` matches. e.g. `Option<usize>` -> `Option<bool>`
`len_without_is_empty` improvements fixes: rust-lang#6958 fixes: rust-lang#6972 changelog: Check the return type of `len`. Only integral types, or an `Option` or `Result` wrapping one. changelog: Ensure the return type of `is_empty` matches. e.g. `Option<usize>` -> `Option<bool>`
Add missing lints to MSRV config doc r? `@giraffate` changelog: Add missing lints to MSRV config doc
Some symbol optimizations changelog: none
Use AnonConst for asm! constants This replaces the old system which used explicit promotion. See rust-lang#83169 for more background. The syntax for `const` operands is still the same as before: `const <expr>`. Fixes rust-lang#83169 Because the implementation is heavily based on inline consts, we suffer from the same issues: - We lose the ability to use expressions derived from generics. See the deleted tests in `src/test/ui/asm/const.rs`. - We are hitting the same ICEs as inline consts, for example rust-lang#78174. It is unlikely that we will be able to stabilize this before inline consts are stabilized.
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
Co-authored-by: Yuki Okushi <jtitor@2k36.org>
Rustup changelog: none r? `@ghost`
Changes `librustc_X` to `rustc_X`, only in documentation comments. Plain code comments are left unchanged. Also fix incorrect file paths.
Improve links in inline code in `core::pin`. ## Context So I recently opened rust-lang#80720. That PR uses HTML-based `<code>foo</code>` syntax in place of `` `foo` `` for some inline code. It looks like usage of `<code>` tags in doc comments is without precedent in the standard library, but the HTML-based syntax has an important advantage: You can write something like ``` <code>[Box]<[Option]\<T>></code> ``` which becomes: <code>[Box]<[Option]\<T>></code>, whereas with ordinary backtick syntax, you cannot create links for a substring of an inline code block. ## Problem I recalled (from my own experience) that a way to partially work around this limitation is to do something like ``` [`Box`]`<`[`Option`]`<T>>` ``` which looks like this: [`Box`]`<`[`Option`]`<T>>` _(admitted, it looks even worse on GitHub than in `rustdoc`’s CSS)_. [Box]: https://doc.rust-lang.org/std/boxed/struct.Box.html "Box" [`Box`]: https://doc.rust-lang.org/std/boxed/struct.Box.html "Box" [Option]: https://doc.rust-lang.org/std/option/enum.Option.html "Option" [`Option`]: https://doc.rust-lang.org/std/option/enum.Option.html "Option" [Pin]: https://doc.rust-lang.org/std/pin/struct.Pin.html "Pin" [&mut]: https://doc.rust-lang.org/std/primitive.reference.html "mutable reference" So I searched the standard library and found that e.g. the [std::pin](https://doc.rust-lang.org/std/pin/index.html) module documentation uses this hack/workaround quite a bit, with types like <code>[Pin]<[Box]\<T>></code> or <code>[Pin]<[&mut] T>></code>. Although the way they look like in this sentence is what I would like them to look like, not what they currently look. ### Status Quo Here’s a screenshot of what it currently looks like:  With a few HTML-style code blocks, we can fix all the spacing issues in the above screenshot that are due usage of this hack/workaround of putting multiple code blocks right next to each other being used. ### after d3915c5:  There’s still a problem of inconsistency. Especially in a sentence such as > A [`Pin<P>`][Pin] where `P: Deref` should be considered as a "`P`-style pointer" to _[...]_ looks weird with the variable `P` having different colors (and `Deref` has a different color from before where it was a link, too). Or compare the difference of <code>[Pin]<[Box]\<T>></code> vs [`Box<T>`][Box] where one time the variable is part of the link and the other time it isn’t. _Note: Color differences show even **more strongly** when the ayu theme is used, while they are a bit less prominent in the light theme than they are in the dark theme, which is the one used for these screenshots._ This is why I’ve added the next commit ### after ceaeb24  pulling all the type parameters out of their links, and also the last commit with clearly visible changes ### after 87ac118  where more links are added, removing e.g. the inconsistency with `Deref`’s color in e.g. `P: Deref` that I already mentioned above. ## Discussion I am aware that this PR may very well be overkill. If for now only the first commit (plus the fix for the `Drop` link in e65385f, the link titles 684edf7 as far as they apply, and a few of the line-break changes) are wanted, I can reduce this PR to just those changes. I personally find the rendered result with all these changes very nice though. On the other hand, all these `<code>` tags are not very nice in the source code, I’ll admit. Perhaps alternative solutions could be preferred, such as `rustdoc` support for merging subsequent inline code blocks so that all the cases that currently use workarounds rendered as [`Box`]`<`[`Option`]`<T>>` automatically become <code>[Box]<[Option]\<T>></code> without any need for further changes. Even in this case, having a properly formatted, better looking example in the standard library docs could help motivate such a change to `rustdoc` by prodiving an example of the expected results and also the already existing alternative (i.e. using `<code>`). On the other hand, `` [`Box`]`<`[`Option`]`<T>>` `` isn’t particularly nice-looking source code either. I’m not even sure if I wouldn’t actually find the version `<code>[Box]<[Option]\<T>></code>` cleaner to read. `@rustbot` modify labels: T-doc, T-rustdoc
Stabilize `rustdoc::bare_urls` lint Closes rust-lang#77501. Closes rust-lang#83598.
Stabilize `peekable_peek_mut` Resolves rust-lang#78302. Also adds some documentation on `std::iter::Iterator::peekable()` regarding the new method. The feature was added in rust-lang#77491 in Nov' 20, which is recently, but the feature seems reasonably small. Never did a stabilization-pr, excuse my ignorance if there is a protocol I'm not aware of.
…s, r=davidtwco Fix outdated crate names in compiler docs Changes `librustc_X` to `rustc_X`, only in documentation comments. Plain code comments are left unchanged.
…iddle Merge idents when generating source content The idea here is to not have a span for each part of a path. Currently, for `a::b::c` we generate `<span>a</span>::<span>b</span>::<span>c</span>`, with this change, we will generate `<span>a::b::c</span>`. A nice "side-effect" is that it reduces the size of the output HTML too. :) cc `@notriddle`
Update Clippy Biweekly Clippy update r? ``@Manishearth``
|
@bors r+ rollup=never p=5 |
|
📌 Commit f77be84 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
This was referenced Apr 8, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
core::pin. #80733 (Improve links in inline code incore::pin.)rustdoc::bare_urlslint #81764 (Stabilizerustdoc::bare_urlslint)peekable_peek_mut#81938 (Stabilizepeekable_peek_mut)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup