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 16 pull requests #82517

Merged
merged 206 commits into from
Feb 25, 2021
Merged

Rollup of 16 pull requests #82517

merged 206 commits into from
Feb 25, 2021

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

camsteffen and others added 30 commits January 2, 2021 18:25
The default value for a field type does not necessarily match the
default value for that field in the struct Default.
There is already an assertion that consecutive lines assign to a struct
field.
[beta] Backport of rust-lang#6375 - field_reassign_with_default fix

With the pinned nightly we can test backports to our beta branch now 🎉

cc rust-lang#6515

changelog: beta 1.50: Backport of private fields fix in [`field_reassign_with_default`] lints
This rewrite gets rid of complicated visitors, by using the lint infrastructure as much as possible
Backport remerge

changelog: none

r? `@ghost`
Update changelog for 1.51

~~Don't merge yet. This is the last step of the release process.~~ Release process for 1.50 is done, this can now be merged.

[Rendered](https://github.com/flip1995/rust-clippy/blob/changelog/CHANGELOG.md)

changelog: none
Rework use_self impl based on ty::Ty comparison rust-lang#3410 | Take 2

This builds on top of rust-lang#5531

I already reviewed and approved the commits by `@montrivo.` So only the review of my commits should be necessary.

I would also appreciate your review `@montrivo,` since you are familiar with the challenges here.

Fixes rust-lang#3410 and Fixes rust-lang#4143 (same problem)
Fixes rust-lang#2843
Fixes rust-lang#3859
Fixes rust-lang#4734 and fixes rust-lang#6221
Fixes rust-lang#4305
Fixes rust-lang#5078 (even at expression level now 🎉)
Fixes rust-lang#3881 and Fixes rust-lang#4887 (same problem)
Fixes rust-lang#3909

Not yet: rust-lang#4140 (test added)

All the credit for the fixes goes to `@montrivo.` I only refactored and copy and pasted his code.

changelog: rewrite [`use_self`] lint and fix multiple (8) FPs. One to go.
Add an impl of Error on `Arc<impl Error>`.

`Display` already exists so this should be a non-controversial change (famous last words).

Would have to be insta-stable.
Make ptr::write const

~~The code in this PR as of right now is not much more than an experiment.~~

~~This should, if I am not mistaken, in theory compile and pass the tests once the bootstraping compiler is updated. Thus the PR is blocked on that which should happen some time after the February the 9th. Also we might want to wait for rust-lang#79989 to avoid regressing performance due to using `mem::forget` over `intrinsics::forget`~~.
…nup, r=jyn514

rustdoc: Name fields of `ResolutionFailure::WrongNamespace`

It makes it clearer that the `Namespace` is the one requested by the
disambiguator, rather than the actual namespace of the item. It said
that in the docs before, but now you can tell in the code so it reduces
the potential for confusion.
…r=oli-obk

Account for associated consts in the "unstable assoc item name colission" lint

Fix rust-lang#81663.
Make char and u8 methods const

char methods `len_utf8`, `len_utf16`, `to_ascii_lowercase`, `eq_ignore_ascii_case` can be made const.

`u8` methods `to_ascii_lowercase`, `to_ascii_uppercase` are required to be const as well.

`u8::eq_ignore_ascii_case` was additionally made const.

Rebase of rust-lang#79549 originally authored by ``@YenForYang.`` Changes from that PR:

- Squashed all commits from rust-lang#79549.
- rebased to latest upstream master.
- Removed const attributes for `char::escape_unicode` and `char::escape_default`.
- Updated `since` attributes for `const` stabilization to 1.52.0.

cc ``@m-ou-se.``
Fix ICE caused by suggestion with no code substitutions

Change suggestion logic to filter and checking _before_ creating
specific resolution suggestion.

Assert earlier that suggestions contain code substitions to make it
easier in the future to debug invalid uses. If we find this becomes too
noisy in the wild, we can always make the emitter resilient to these
cases and remove the assertions.

Fix rust-lang#78651.
…n-here, r=estebank

Do not consider using a semicolon inside of a different-crate macro

Fixes rust-lang#81943
fix the false 'defined here' messages

Closes rust-lang#80853.

Take this code:

```rust
struct S;

fn repro_ref(thing: S) {
    thing();
}
```

Previously, the error message would be this:

```
error[E0618]: expected function, found `S`
 --> src/lib.rs:4:5
  |
3 | fn repro_ref(thing: S) {
  |              ----- `S` defined here
4 |     thing();
  |     ^^^^^--
  |     |
  |     call expression requires function

error: aborting due to previous error
```

This is incorrect as `S` is not defined in the function arguments, `thing` is defined there. With this change, the following is emitted:

```
error[E0618]: expected function, found `S`
  --> $DIR/80853.rs:4:5
   |
LL | fn repro_ref(thing: S) {
   |              ----- is of type `S`
LL |     thing();
   |     ^^^^^--
   |     |
   |     call expression requires function
   |
   = note: local variable `S` is not a function

error: aborting due to previous error
```

As you can see, this error message points out that `thing` is of type `S` and later in a note, that `S` is not a function. This change does seem like a downside for some error messages. Take this example:

```
LL | struct Empty2;
   | -------------- is of type `Empty2`
```

As you can see, the error message shows that the definition of `Empty2` is of type `Empty2`. Although this isn't wrong, it would be more helpful if it would say something like this (which was there previously):

```
LL | struct Empty2;
   | -------------- `Empty2` defined here
```

If there is a better way of doing this, where the `Empty2` example would stay the same as without this change, please inform me.

**Update: This is now fixed**

CC `@camelid`
…umeGomez

Update normalize.css to 8.0.1

From From https://github.com/necolas/normalize.css/releases/tag/8.0.1.

The old version was 3.0.0, from 2014. The new version is from 2018.

I noticed when looking at frontend performance for rustdoc that this file was out of date. The URL in the 3.0.0 license header now resolves to an incorrect destination. And generally it seems good to be up-to-date.

Before-and-after images, plus diff, under details. TL;DR: Nothing changes except a slight adjustment to line height.

<details>

![with-normalize-8 0 1](https://user-images.githubusercontent.com/220205/108581849-bd5c8800-72e4-11eb-9150-78c8d67ca37a.png)

![with-normalize-3 0 0](https://user-images.githubusercontent.com/220205/108581848-bcc3f180-72e4-11eb-8b45-0cd1415a51e5.png)

![diff](https://user-images.githubusercontent.com/220205/108581890-dfeea100-72e4-11eb-93c5-6284492f54a9.png)

</details>
AST: Remove some unnecessary boxes
Improve error msgs when found type is deref of expected

This improves help messages in two cases:

- When expected type is `T` and found type is `&T`, we now look through blocks
  and suggest dereferencing the expression of the block, rather than the whole
  block.

- In the above case, if the expression is an `&`, we not suggest removing the
  `&` instead of adding `*`.

Both of these are demonstrated in the regression test. Before this patch the
first error in the test would be:

    error[E0308]: `if` and `else` have incompatible types
     --> test.rs:8:9
      |
    5 | /     if true {
    6 | |         a
      | |         - expected because of this
    7 | |     } else {
    8 | |         b
      | |         ^ expected `usize`, found `&usize`
    9 | |     };
      | |_____- `if` and `else` have incompatible types
      |
    help: consider dereferencing the borrow
      |
    7 |     } else *{
    8 |         b
    9 |     };
      |

Now:

    error[E0308]: `if` and `else` have incompatible types
     --> test.rs:8:9
      |
    5 | /     if true {
    6 | |         a
      | |         - expected because of this
    7 | |     } else {
    8 | |         b
      | |         ^
      | |         |
      | |         expected `usize`, found `&usize`
      | |         help: consider dereferencing the borrow: `*b`
    9 | |     };
      | |_____- `if` and `else` have incompatible types

The second error:

    error[E0308]: `if` and `else` have incompatible types
      --> test.rs:14:9
       |
    11 | /     if true {
    12 | |         1
       | |         - expected because of this
    13 | |     } else {
    14 | |         &1
       | |         ^^ expected integer, found `&{integer}`
    15 | |     };
       | |_____- `if` and `else` have incompatible types
       |
    help: consider dereferencing the borrow
       |
    13 |     } else *{
    14 |         &1
    15 |     };
       |

now:

    error[E0308]: `if` and `else` have incompatible types
      --> test.rs:14:9
       |
    11 | /     if true {
    12 | |         1
       | |         - expected because of this
    13 | |     } else {
    14 | |         &1
       | |         ^-
       | |         ||
       | |         |help: consider removing the `&`: `1`
       | |         expected integer, found `&{integer}`
    15 | |     };
       | |_____- `if` and `else` have incompatible types

Fixes rust-lang#82361

---

r? ````@estebank````
Update Clippy

Bi-weekly Clippy update.

This updates `Cargo.lock`, so probably needs rollup=never. (rust-lang@0046d7c)

rust-lang@a6dd9b9 fixes things in Clippy, so that it can be build and tested. This needs proper fixing in Clippy, but I didn't want this to block the sync.

r? `@Manishearth`
@rustbot rustbot added the rollup A PR which is a rollup label Feb 25, 2021
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Feb 25, 2021

📌 Commit ebe67d9 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 Feb 25, 2021
@bors
Copy link
Contributor

bors commented Feb 25, 2021

⌛ Testing commit ebe67d9 with merge 0ab7c1d...

@bors
Copy link
Contributor

bors commented Feb 25, 2021

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing 0ab7c1d 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.