Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 6 pull requests #84008

Merged
merged 169 commits into from
Apr 8, 2021
Merged

Rollup of 6 pull requests #84008

merged 169 commits into from
Apr 8, 2021

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

steffahn and others added 30 commits January 5, 2021 17:08
…the markdown link definition names being case insensitive.
Co-authored-by: Takayuki Nakata <[email protected]>
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 <[email protected]>
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
bors and others added 17 commits April 7, 2021 04:36
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.
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:
![Screenshot_20210105_202751](https://user-images.githubusercontent.com/3986214/103692608-4a978780-4f98-11eb-9451-e13622b2e3c0.png)

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:
![Screenshot_20210105_202932](https://user-images.githubusercontent.com/3986214/103692688-6f8bfa80-4f98-11eb-9be5-9b370eaef644.png)

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
![Screenshot_20210105_203113](https://user-images.githubusercontent.com/3986214/103693496-ab738f80-4f99-11eb-942d-29dace459734.png)
pulling all the type parameters out of their links, and also the last commit with clearly visible changes
### after 87ac118
![Screenshot_20210105_203252](https://user-images.githubusercontent.com/3986214/103693625-e5dd2c80-4f99-11eb-91b7-470c37934e7e.png)
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 `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``
@rustbot rustbot added the rollup A PR which is a rollup label Apr 8, 2021
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Apr 8, 2021

📌 Commit f77be84 has been approved by Dylan-DPC

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Apr 8, 2021
@bors
Copy link
Contributor

bors commented Apr 8, 2021

⌛ Testing commit f77be84 with merge 2e495d2...

@bors
Copy link
Contributor

bors commented Apr 8, 2021

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing 2e495d2 to master...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.