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 7 pull requests #92049

Closed
wants to merge 20 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

camelid and others added 20 commits December 11, 2021 17:58
I think it's helpful to know what type was unused when looking at these
warnings. The type will likely determine whether the result *should* be
used, or whether it should just be ignored.

Including the type also matches the behavior of the `must_use` lint:
unused `SomeType` that must be used.
Given

```rust
match Some(42) {}
```

suggest

```rust
match Some(42) { None | Some(_) => todo!(), }
```
…st it

Given

```rust
match Some(42) {
    Some(0) => {}
}
```

suggest

```rust
match Some(42) {
    Some(0) => {}
    None | Some(_) => todo!(),
}
```
…est it

Given

```rust
match Some(42) {
    Some(0) => {}
    Some(1) => {}
}
```

suggest

```rust
match Some(42) {
    Some(0) => {}
    Some(1) => {}
    None | Some(_) => todo!(),
}
```
… `span_label`

This makes the order of the output always consistent:

1. Place of the `match` missing arms
2. The `enum` definition span
3. The structured suggestion to add a fallthrough arm
platforms, not just Apple ones.

To avoid breaking split DWARF, we need to ensure that each codegen unit has a
unique `DW_AT_name`. This is because there's a remote chance that different
codegen units for the same module will have entirely identical DWARF entries
for the purpose of the DWO ID, which would violate Appendix F ("Split Dwarf
Object Files") of the DWARF 5 specification. LLVM uses the algorithm specified
in section 7.32 "Type Signature Computation" to compute the DWO ID, which does
not include any fields that would distinguish compilation units. So we must
embed the codegen unit name into the `DW_AT_name`.

Closes rust-lang#88521.
Show the unused type for `unused_results` lint

I think it's helpful to know what type was unused when looking at these
warnings. The type will likely determine whether the result *should* be
used, or whether it should just be ignored.

Including the type also matches the behavior of the `must_use` lint:
unused `SomeType` that must be used.
miri: lift restriction on extern types being the only field in a struct

Fixes rust-lang#91827.

r? ```@RalfJung```
Constify (most) `Option` methods

r? `@oli-obk`
…li-obk

Tweak output for non-exhaustive `match` expression

* Provide structured suggestion when missing `match` arms
* Move pointing at the missing variants *after* the main error

<img width="1164" alt="" src="https://user-images.githubusercontent.com/1606434/146312085-b57ef4a3-6e96-4f32-aa2a-803637d9eeba.png">
…sing, r=Amanieu

builtin_macros: allow external consumers for AsmArgs parsing

As discussed in Zulip (https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/parsing.20of.20AsmArgs.20for.20inline.20assembly), we need a function entry point that rustfmt can leverage from a pre-expansion context to get a more structured representation of the asm args without having to duplicate/maintain the token stream parsing

r? ``@Amanieu`` and/or ``@joshtriplett``
…davidtwco

rustc_codegen_llvm: Give each codegen unit a unique DWARF name on all platforms, not just Apple ones.

To avoid breaking split DWARF, we need to ensure that each codegen unit has a
unique `DW_AT_name`. This is because there's a remote chance that different
codegen units for the same module will have entirely identical DWARF entries
for the purpose of the DWO ID, which would violate Appendix F ("Split Dwarf
Object Files") of the DWARF 5 specification. LLVM uses the algorithm specified
in section 7.32 "Type Signature Computation" to compute the DWO ID, which does
not include any fields that would distinguish compilation units. So we must
embed the codegen unit name into the `DW_AT_name`.

Closes rust-lang#88521.
…d, r=kennytm

Revert "socket ancillary data implementation for dragonflybsd."

Reverts rust-lang#91553
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Dec 17, 2021
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented Dec 17, 2021

📌 Commit 51df63f has been approved by matthiaskrgr

@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 Dec 17, 2021
@matthiaskrgr
Copy link
Member Author

@bors r-
let#s wait for #89841 to start first :)

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 17, 2021
@matthiaskrgr
Copy link
Member Author

@bors r+

@bors
Copy link
Contributor

bors commented Dec 17, 2021

📌 Commit 51df63f has been approved by matthiaskrgr

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 17, 2021
@bors
Copy link
Contributor

bors commented Dec 18, 2021

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

  1. git checkout rollup-vhntztu (switch to your branch)
  2. git fetch upstream master (retrieve the latest master)
  3. git rebase upstream/master -p (rebase on top of it)
  4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
  5. git push self rollup-vhntztu --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message
Auto-merging compiler/rustc_mir_build/src/thir/pattern/check_match.rs
CONFLICT (content): Merge conflict in compiler/rustc_mir_build/src/thir/pattern/check_match.rs
Automatic merge failed; fix conflicts and then commit the result.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 18, 2021
@bors
Copy link
Contributor

bors commented Dec 18, 2021

☔ The latest upstream changes (presumably #89841) made this pull request unmergeable. Please resolve the merge conflicts.

@jackh726 jackh726 closed this Dec 18, 2021
@matthiaskrgr matthiaskrgr deleted the rollup-vhntztu branch January 2, 2022 22:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.