Skip to content
New issue

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

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

Already on GitHub? # to your account

Rollup of 11 pull requests #94531

Closed
wants to merge 41 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

sunfishcode and others added 30 commits January 26, 2022 16:27
Following up on rust-lang#88564, this adds documentation explaining why
`BorrowedFd::to_owned` returns another `BorrowedFd` rather than an
`OwnedFd`. And similar for `BorrowedHandle` and `BorrowedSocket`.
This change weakens the descriptions of the
`{as,into,from}_raw_{fd,handle,socket}` descriptions from saying that
they *do* express ownership relations to say that they are *typically used*
in ways that express ownership relations. This needed needed since, for
example, std's own [`RawFd`] implements `{As,From,Into}Fd` without any of
the ownership relationships.

This adds proper `# Safety` comments to `from_raw_{fd,handle,socket}`,
adds the requirement that raw handles be not opened with the
`FILE_FLAG_OVERLAPPED` flag, and merges the `OwnedHandle::from_raw_handle`
comment into the main `FromRawHandle::from_raw_handle` comment.

And, this changes `HandleOrNull` and `HandleOrInvalid` to not implement
`FromRawHandle`, since they are intended for limited use in FFI situations,
and not for generic use, and they have constraints that are stronger than
the those of `FromRawHandle`.

[`RawFd`]: https://doc.rust-lang.org/stable/std/os/unix/io/type.RawFd.html
This function is documented in more detail in the `FromRawSocket` trait.
Also, rename `BorrowedHandle::borrow_raw_handle` and
`BorrowedSocket::borrow_raw_socket` to `BorrowedHandle::borrow_raw` and
`BorrowedSocket::borrow_raw`.

This is just a minor rename to reduce redundancy in the user code calling
these functions, and to eliminate an inessential difference between
`BorrowedFd` code and `BorrowedHandle`/`BorrowedSocket` code.

While here, add a simple test exercising `BorrowedFd::borrow_raw_fd`.
Only point at the end of the crate. We could try making it point at the
beginning of the crate, but that is confused with `DUMMY_SP`, causing
the output to be *worse*.

This change will make it so that VSCode will *not* underline the whole
file when `main` is missing, so other errors will be visible.
Add `rustc_middle::ty::suggest_constraining_type_params` that suggests
adding multiple constraints.

`suggest_constraining_type_param` now just forwards params to this new
function.
Previously we've only suggested adding `Copy` bounds when the type being
moved/copied is a type parameter (generic). With this commit we also
suggest adding bounds when a type
- Can be copy
- All predicates that need to be satisfied for that are based on type
  params

i.e. we will suggest `T: Copy` for `Option<T>`, but won't suggest
anything for `Option<String>`.

Future work: it would be nice to also suggest adding `.clone()` calls
Modify the tier 3 non-ARM targets to show the standard library will no longer build for these and there is no work being done to change that.
adds more archs for openbsd: arm, mips64, powerpc, powerpc64, and riscv64.
update char signess for openbsd

it adds more archs support for openbsd: arm, mips64, powerpc, powerpc64, and riscv64.
Do not point at whole file missing `fn main`

Only point at the end of the crate. We could try making it point at the
beginning of the crate, but that is confused with `DUMMY_SP`, causing
the output to be *worse*.

This change will make it so that VSCode will *not* underline the whole
file when `main` is missing, so other errors will be visible.
…rrowedfd-toowned, r=joshtriplett

Add documentation about `BorrowedFd::to_owned`.

Following up on rust-lang#88564, this adds documentation explaining why
`BorrowedFd::to_owned` returns another `BorrowedFd` rather than an
`OwnedFd`. And similar for `BorrowedHandle` and `BorrowedSocket`.

r? `@joshtriplett`
…joshtriplett

Update the documentation for `{As,Into,From}Raw{Fd,Handle,Socket}`.

This change weakens the descriptions of the
`{as,into,from}_raw_{fd,handle,socket}` descriptions from saying that
they *do* express ownership relations to say that they are *typically used*
in ways that express ownership relations. This is needed since, for
example, std's own [`RawFd`] implements `{As,From,Into}Fd` without any of
the ownership relationships.

This adds proper `# Safety` comments to `from_raw_{fd,handle,socket}`,
adds the requirement that raw handles be not opened with the
`FILE_FLAG_OVERLAPPED` flag, and merges the `OwnedHandle::from_raw_handle`
comment into the main `FromRawHandle::from_raw_handle` comment.

And, this changes `HandleOrNull` and `HandleOrInvalid` to not implement
`FromRawHandle`, since they are intended for limited use in FFI situations,
and not for generic use, and they have constraints that are stronger than
the those of `FromRawHandle`.

[`RawFd`]: https://doc.rust-lang.org/stable/std/os/unix/io/type.RawFd.html
…, r=joshtriplett

Rename `BorrowedFd::borrow_raw_fd` to `BorrowedFd::borrow_raw`.

Also, rename `BorrowedHandle::borrow_raw_handle` and
`BorrowedSocket::borrow_raw_socket` to `BorrowedHandle::borrow_raw` and
`BorrowedSocket::borrow_raw`.

This is just a minor rename to reduce redundancy in the user code calling
these functions, and to eliminate an inessential difference between
`BorrowedFd` code and `BorrowedHandle`/`BorrowedSocket` code.

While here, add a simple test exercising `BorrowedFd::borrow_raw_fd`.

r? `@joshtriplett`
Ensure stability directives are checked in all cases

Split off  rust-lang#93017

Stability and deprecation were not checked in all cases, for instance if a type error happened.
This PR moves the check earlier in the pipeline to ensure the errors are emitted in all cases.

r? ````@lcnr````
…ebank

Adt copy suggestions

Previously we've only suggested adding `Copy` bounds when the type being moved/copied is a type parameter (generic). With this PR we also suggest adding bounds when a type
- Can be copy
- All predicates that need to be satisfied for that are based on type params

i.e. we will suggest `T: Copy` for `Option<T>`, but won't suggest anything for `Option<String>`.

An example:
```rust
fn duplicate<T>(t: Option<T>) -> (Option<T>, Option<T>) {
    (t, t)
}
```
New error (current compiler doesn't provide `help`:):
```text
error[E0382]: use of moved value: `t`
 --> t.rs:2:9
  |
1 | fn duplicate<T>(t: Option<T>) -> (Option<T>, Option<T>) {
  |                 - move occurs because `t` has type `Option<T>`, which does not implement the `Copy` trait
2 |     (t, t)
  |      -  ^ value used here after move
  |      |
  |      value moved here
  |
help: consider restricting type parameter `T`
  |
1 | fn duplicate<T: Copy>(t: Option<T>) -> (Option<T>, Option<T>) {
  |               ++++++
```

Fixes rust-lang#93623
r? `````@estebank`````
`````@rustbot````` label +A-diagnostics +A-suggestion-diagnostics +C-enhancement

----

I'm not at all sure if this is the right implementation for this kind of suggestion, but it seems to work :')
…henkov

Improve allowness of the unexpected_cfgs lint

This pull-request improve the allowness (`#[allow(...)]`) of the `unexpected_cfgs` lint.

Before this PR only crate level `#![allow(unexpected_cfgs)]` worked, now with this PR it also work when put around `cfg!` or if it is in a upper level. Making it work ~for the attributes `cfg`, `cfg_attr`, ...~ for the same level is awkward as the current code is design to give "Some parent node that is close to this macro call" (cf. https://doc.rust-lang.org/nightly/nightly-rustc/rustc_expand/base/struct.ExpansionData.html) meaning that allow on the same line as an attribute won't work. I'm note even sure if this would be possible.

Found while working on rust-lang#94298.
r? ``````@petrochenkov``````
Documentation was missed when demoting Windows XP to no_std only

After a quick discussion on rust-lang#81250 which removed special casing for mutexes added [here](rust-lang@10b103a) to support Windows XP, we can't say that the standard library can build for it.

This change modifies the tier 3 non-ARM targets to show the standard library will no longer build for these and there is no work being done to change that.
Miri/CTFE: properly treat overflow in (signed) division/rem as UB

To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR `Div`/`Rem` directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.

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

Remove num_cpus dependency from bootstrap, build-manifest and rustc_s…

…ession

`std::threads::available_parallelism` was stabilized in rust 1.59.

r? `@Mark-Simulacrum`
@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 Mar 2, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=11

@bors
Copy link
Contributor

bors commented Mar 2, 2022

📌 Commit be86bac 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 Mar 2, 2022
@matthiaskrgr matthiaskrgr deleted the rollup-jp6asky branch March 11, 2022 15:32
# for free to join this conversation on GitHub. Already have an account? # 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.