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 5 pull requests #97781

Closed
wants to merge 17 commits into from
Closed

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

GuillaumeGomez and others added 17 commits May 31, 2022 14:02
…and implicit provenance stripping where possible
Co-authored-by: Michael Goulet <michael@errs.io>
…=jsha

Add empty impl blocks if they have documentation

Fixes rust-lang#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 rust-lang#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``
… r=oli-obk

interpret: better control over whether we read data with provenance

The resolution in rust-lang/unsafe-code-guidelines#286 seems to be that when we load data at integer type, we implicitly strip provenance. So let's implement that in Miri at least for scalar loads. This makes use of the fact that `Scalar` layouts distinguish pointer-sized integers and pointers -- so I was expecting some wild bugs where layouts set this incorrectly, but so far that does not seem to happen.

This does not entirely implement the solution to rust-lang/unsafe-code-guidelines#286; we still do the wrong thing for integers in larger types: we will `copy_op` them and then do validation, and validation will complain about the provenance. To fix that we need mutating validation; validation needs to strip the provenance rather than complaining about it. This is a larger undertaking (but will also help resolve rust-lang/miri#845 since we can reset padding to `Uninit`).

The reason this is useful is that we can now implement `addr` as a `transmute` from a pointer to an integer, and actually get the desired behavior of stripping provenance without exposing it!
…h726

Do `suggest_await_before_try` with infer variables in self, and clean up binders

Fixes rust-lang#97704

Also cleans up binders in this fn, since everything is a `Poly*` and we really shouldn't have stray escaping late-bound regions everywhere. That's why the function changed so much. This isn't necessary, so I can revert if necessary.
typo: `-Zcodegen-backend=llvm -Cpasses=list` should work now

r? ``@bjorn3``
…compiler-errors

Suggest adding `{}` for `'label: non_block_expr`

Adds suggestions like this:
```text
help: consider enclosing expression in a block
  |
3 |     'l {0};
  |        + +
```

inspired by rust-lang#48594 (comment)

r? `@compiler-errors`
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jun 6, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Jun 6, 2022

📌 Commit d701e5b 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 Jun 6, 2022
@JohnTitor
Copy link
Member

@Dylan-DPC Why did you close #97766 (failed with timeout) and created the exact same size of rollup instead of retrying? And this is marked as rollup=always wrongly.

@Dylan-DPC
Copy link
Member Author

@bors rollup=never p=5

@Dylan-DPC
Copy link
Member Author

@JohnTitor if a rollup has remained for a long time, i usually close it and create a new one because some of those might get merged, or r-'d or sometimes we may need a bigger rollup if queue is longer. (i know rollup pr does show if prs are merged or not)

Choosing the same prs was purely accidental :P

@Dylan-DPC
Copy link
Member Author

closing in favour of #97783

@Dylan-DPC Dylan-DPC closed this Jun 6, 2022
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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants