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 13 pull requests #98723

Closed
wants to merge 206 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

ebobrow and others added 30 commits May 16, 2022 20:20
…that_are_quite_far_away_from_each_other, r=estebank

Hide irrelevant lines in suggestions to allow for suggestions that are far from each other to be shown

This is an attempt to fix suggestions one part of which is 6 lines or more far from the first. I've noticed "the problem" (of not showing some parts of the suggestion) here: rust-lang#97759 (comment).

I'm not sure about the implementation (this big closure is just bad and makes already complicated code even more so), but I want to at least discuss the result.

Here is an example of how this changes the output:

Before:
```text
help: consider enclosing expression in a block
  |
3 ~     'l: { match () { () => break 'l,
4 |
5 |
6 |
7 |
8 |
...
```

After:
```text
help: consider enclosing expression in a block
  |
3 ~     'l: { match () { () => break 'l,
4 |
...
31|
32~ } };
  |
```

r? `@estebank`
`@rustbot` label +A-diagnostics +A-suggestion-diagnostics
…to-string, r=Dylan-DPC

Remove the rest of unnecessary `to_string`

I removed most of unnecessary `to_string` in rust-lang#98043. This patch removes the rest of them I missed.
Update description in clippy_lints/src/default_iter_empty.rs

Co-authored-by: Fridtjof Stoldt <xFrednet@gmail.com>

Update clippy_lints/src/default_iter_empty.rs

Co-authored-by: Alex Macleod <alex@macleod.io>

Update clippy_lints/src/default_iter_empty.rs

Co-authored-by: Alex Macleod <alex@macleod.io>

renamed default_iter_empty to default_instead_of_iter_empty

Avoid duplicate messages

add tests for regression

rewrite 'Why is this bad?'

cargo dev fmt

delete default_iter_empty lint in renamed_lint.rs

rewrite a message in the suggestion

cargo dev update_lints --check
diagnostics: remove trailing spaces

Remove few occurrences of trailing spaces and drive by fix of needless alloc of const string.
feat(lint): add default_iter_empty

close rust-lang#8915

This PR adds `default_iter_empty` lint.

This lint checks `std::iter::Empty::default()` and replace with `std::iter::empty()`.

Thank you in advance.

---

changelog: add `default_instead_of_iter_empty` lint.
[core] add `Exclusive` to sync

(discussed here: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20.60SyncWrapper.60.20to.20std)

`Exclusive` is a wrapper that exclusively allows mutable access to the inner value if you have exclusive access to the wrapper. It acts like a compile time mutex, and hold an unconditional `Sync` implementation.

## Justification for inclusion into std
- This wrapper unblocks actual problems:
  - The example that I hit was a vector of `futures::future::BoxFuture`'s causing a central struct in a script to be non-`Sync`. To work around it, you either write really difficult code, or wrap the futures in a needless mutex.
- Easy to maintain: this struct is as simple as a wrapper can get, and its `Sync` implementation has very clear reasoning
- Fills a gap: `&/&mut` are to `RwLock` as `Exclusive` is to `Mutex`

## Public Api
```rust
// core::sync
#[derive(Default)]
struct Exclusive<T: ?Sized> { ... }

impl<T: ?Sized> Sync for Exclusive {}

impl<T> Exclusive<T> {
    pub const fn new(t: T) -> Self;
    pub const fn into_inner(self) -> T;
}

impl<T: ?Sized> Exclusive<T> {
    pub const fn get_mut(&mut self) -> &mut T;
    pub const fn get_pin_mut(Pin<&mut self>) -> Pin<&mut T>;
    pub const fn from_mut(&mut T) -> &mut Exclusive<T>;
    pub const fn from_pin_mut(Pin<&mut T>) -> Pin<&mut Exclusive<T>>;
}

impl<T: Future> Future for Exclusive { ... }

impl<T> From<T> for Exclusive<T> { ... }
impl<T: ?Sized> Debug for Exclusive { ... }
```

## Naming
This is a big bikeshed, but I felt that `Exclusive` captured its general purpose quite well.

## Stability and location
As this is so simple, it can be in `core`. I feel that it can be stabilized quite soon after it is merged, if the libs teams feels its reasonable to add. Also, I don't really know how unstable feature work in std/core's codebases, so I might need help fixing them

## Tips for review
The docs probably are the thing that needs to be reviewed! I tried my best, but I'm sure people have more experience than me writing docs for `Core`

### Implementation:
The API is mostly pulled from https://docs.rs/sync_wrapper/latest/sync_wrapper/struct.SyncWrapper.html (which is apache 2.0 licenesed), and the implementation is trivial:
- its an unsafe justification for pinning
- its an unsafe justification for the `Sync` impl (mostly reasoned about by ``@danielhenrymantilla`` here: Actyx/sync_wrapper#2)
- and forwarding impls, starting with derivable ones and `Future`
fix data race in thread::scope

Puts the `ScopeData` into an `Arc` so it sticks around as long as we need it.
This means one extra `Arc::clone` per spawned scoped thread, which I hope is fine.

Fixes rust-lang#98498
r? ```@m-ou-se```
…ler-errors

Factor out `hir::Node::Binding`
…Value, r=nikic

llvm-wrapper: adapt for LLVMConstExtractValue removal

`LLVMConstExtractValue` was removed recently from LLVM: llvm/llvm-project@5548e80.

This adapts llvm-wrapper to use the new alternative where available, following https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/LLVMConstExtractValue.20removal.
…, r=notriddle

Fix source sidebar bugs

This PR fixes the following two bugs:

![Screenshot from 2022-06-29 14-39-58](https://user-images.githubusercontent.com/3050060/176449070-3e3762da-2bfe-4acf-8eb0-34f6eb4c94ed.png)
![Screenshot from 2022-06-29 15-05-09](https://user-images.githubusercontent.com/3050060/176449073-b164820b-bd71-4b1a-990c-bba4e5fce196.png)

I added regression tests to prevent them to happen again.

I think we should backport it to beta as well.

You can test it [here](https://rustdoc.crud.net/imperio/source-sidebar-fixes/src/std/lib.rs.html).

cc `@jsha`
r? `@notriddle`
For diagnostic information of Boolean, remind it as use the type: 'bool'

Fixes rust-lang#98492.

It helps programmers coming from other languages
	modified:   compiler/rustc_resolve/src/late/diagnostics.rs
interpret: add From<&MplaceTy> for PlaceTy

We have a similar instance for `&MPlaceTy` to `OpTy`. Also add the same for `&mut`.

This avoids having to write `&(*place).into()`, which we have a few times here and at least twice in Miri (and it comes up again in my current patch).

r? `@oli-obk`
…llaumeGomez

rustdoc: fix 98690 Panic if invalid path for -Z persist-doctests

Closes rust-lang#98690 for rustdoc panic

I changed this to do eprintln and orderly panic instead of unwrap doing unhandled panic

~/gg/rust/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc --test -Z unstable-options --persist-doctests /tmp/foobar main.rs
Couldn't create directory for doctest executables: Permission denied (os error 13)
…sers, r=Dylan-DPC

Remove unneeded methods declaration for old web browsers

All these methods were not defined for IE mostly. But since we don't support it anymore, no need to keep them around.

cc `@jsha`
r? `@notriddle`
…=jyn514

get rid of tidy 'unnecessarily ignored' warnings

I think these warnings are quite pointless: when I say `allow(foo)` in my code, that doesn't necessarily mean that I expect `foo` to happen -- it just means that I am okay with `foo` happening.

For example, having to add and remove `ignore-tidy-linelength` as the longest line in the file keeps growing and shrinking is just annoying and doesn't benefit anyone, IMO. This usually incurs *two* CI roundtrips: first CI tells you that line lengths in your test file are ignored unnecessarily, so you go and remove that attribute; then CI tells you that now your line numbers changed, so you re-bless your tests (often takes >5min if parts of rustc need rebuilding because `./x.py fmt` changed something somewhere). That's just a lot of wasted effort and time and patience.
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library 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 30, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=13

@bors
Copy link
Contributor

bors commented Jun 30, 2022

📌 Commit 4bd8c92 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 Jun 30, 2022
@bors
Copy link
Contributor

bors commented Jun 30, 2022

⌛ Testing commit 4bd8c92 with merge c73d2b55a628498a5894f9546f9582291de30fd8...

@bors
Copy link
Contributor

bors commented Jun 30, 2022

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 30, 2022
@rust-log-analyzer
Copy link
Collaborator

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
    Checking clippy_lints v0.1.64 (/checkout/src/tools/clippy/clippy_lints)
error[E0599]: no variant or associated item named `Binding` found for enum `rustc_hir::Node` in the current scope
  --> src/tools/clippy/clippy_lints/src/manual_rem_euclid.rs:75:31
   |
75 |             && let Some(Node::Binding(_)) = cx.tcx.hir().find(hir_id) {
   |                               ^^^^^^^ variant or associated item not found in `rustc_hir::Node<'_>`
For more information about this error, try `rustc --explain E0599`.
error: could not compile `clippy_lints` due to previous error
Build completed unsuccessfully in 0:04:00

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-debug failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
    Checking clippy_lints v0.1.64 (/checkout/src/tools/clippy/clippy_lints)
error[E0599]: no variant or associated item named `Binding` found for enum `rustc_hir::Node` in the current scope
  --> src/tools/clippy/clippy_lints/src/manual_rem_euclid.rs:75:31
   |
75 |             && let Some(Node::Binding(_)) = cx.tcx.hir().find(hir_id) {
   |                               ^^^^^^^ variant or associated item not found in `rustc_hir::Node<'_>`
For more information about this error, try `rustc --explain E0599`.
error: could not compile `clippy_lints` due to previous error
Build completed unsuccessfully in 0:03:54

@matthiaskrgr matthiaskrgr deleted the rollup-98zkpt9 branch July 30, 2022 10:32
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-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library 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.