async/await: improve not-send errors, part 2
Part of #64130. Fixes#65667.
This PR improves the errors introduced in #64895 so that they have specialized messages for `Send` and `Sync`.
r? @nikomatsakis
Update hashmap doc
Update hint to the used algorithms. Skimmed over the longer description but could not find another mentioning of the old algorithms.
Closes#67093
Change unused_labels from allow to warn
Fixes#66324, making the unused_labels lint warn instead of allow by default. I'm told @rust-lang/lang will need to review this, and perhaps will want to do a crater run.
Rollup of 10 pull requests
Successful merges:
- #66649 (VxWorks: fix issues in accessing environment variables)
- #66764 (Tweak wording of `collect()` on bad target type)
- #66900 (Clean up error codes)
- #66974 ([CI] fix the `! isCI` check in src/ci/run.sh)
- #66979 (Add long error for E0631 and update ui tests.)
- #67017 (cleanup long error explanations)
- #67021 (Fix docs for formatting delegations)
- #67041 (add ExitStatusExt into prelude)
- #67065 (Fix fetching arguments on the wasm32-wasi target)
- #67066 (Update the revision of wasi-libc used in wasm32-wasi)
Failed merges:
r? @ghost
Fix fetching arguments on the wasm32-wasi target
Fixes an error introduced in #66750 where wasi executables always think
they have zero arguments because one of the vectors returned here
accidentally thought it was length 0.
std:win: avoid WSA_FLAG_NO_INHERIT flag and don't use SetHandleInformation on UWP
This flag is not supported on Windows 7 before SP1, and on windows server 2008 SP2. This breaks Socket creation & duplication.
This was fixed in a previous PR. cc #26658
This PR: cc #60260 reuses this flag to support UWP, and makes an attempt to handle the potential error.
This version still fails to create a socket, as the error returned by WSA on this case is WSAEINVAL (invalid argument). and not WSAEPROTOTYPE.
MSDN page for WSASocketW (that states the platform support for WSA_FLAG_NO_HANDLE_INHERIT): https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsasocketw
CC #26543
CC #26518
Fixes an error introduced in #66750 where wasi executables always think
they have zero arguments because one of the vectors returned here
accidentally thought it was length 0.
Update the `wasi` crate for `wasm32-wasi`
This commit updates the `wasi` crate used by the standard library which
is used to implement most of the functionality of libstd on the
`wasm32-wasi` target. This update comes with a brand new crate structure
in the `wasi` crate which caused quite a few changes for the wasi target
here, but it also comes with a significant change to where the
functionality is coming from.
The WASI specification is organized into "snapshots" and a new snapshot
happened recently, so the WASI APIs themselves have changed since the
previous revision. This had only minor impact on the public facing
surface area of libstd, only changing on `u32` to a `u64` in an unstable
API. The actual source for all of these types and such, however, is now
coming from the `wasi_preview_snapshot1` module instead of the
`wasi_unstable` module like before. This means that any implementors
generating binaries will need to ensure that their embedding environment
handles the `wasi_preview_snapshot1` module.
This commit updates the `wasi` crate used by the standard library which
is used to implement most of the functionality of libstd on the
`wasm32-wasi` target. This update comes with a brand new crate structure
in the `wasi` crate which caused quite a few changes for the wasi target
here, but it also comes with a significant change to where the
functionality is coming from.
The WASI specification is organized into "snapshots" and a new snapshot
happened recently, so the WASI APIs themselves have changed since the
previous revision. This had only minor impact on the public facing
surface area of libstd, only changing on `u32` to a `u64` in an unstable
API. The actual source for all of these types and such, however, is now
coming from the `wasi_preview_snapshot1` module instead of the
`wasi_unstable` module like before. This means that any implementors
generating binaries will need to ensure that their embedding environment
handles the `wasi_preview_snapshot1` module.
Atomic as_mut_ptr
I encountered the following pattern a few times: In Rust we use some atomic type like `AtomicI32`, and an FFI interface exposes this as `*mut i32` (or some similar `libc` type).
It was not obvious to me if a just transmuting a pointer to the atomic was acceptable, or if this should use a cast that goes through an `UnsafeCell`. See https://github.com/rust-lang/rust/issues/66136#issuecomment-557802477
Transmuting the pointer directly:
```rust
let atomic = AtomicI32::new(1);
let ptr = &atomic as *const AtomicI32 as *mut i32;
unsafe {
ffi(ptr);
}
```
A dance with `UnsafeCell`:
```rust
let atomic = AtomicI32::new(1);
unsafe {
let ptr = (&*(&atomic as *const AtomicI32 as *const UnsafeCell<i32>)).get();
ffi(ptr);
}
```
Maybe in the end both ways could be valid. But why not expose a direct method to get a pointer from the standard library?
An `as_mut_ptr` method on atomics can be safe, because only the use of the resulting pointer is where things can get unsafe. I documented its use for FFI, and "Doing non-atomic reads and writes on the resulting integer can be a data race."
The standard library could make use this method in a few places in the WASM module.
cc @RalfJung as you answered my original question.
Format libstd with rustfmt
(Same strategy as #66691.)
This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd *that are not involved in any currently open PR* to minimize merge conflicts, and are not part of libstd/os (#66818) or libstd/sys (#66819). The list of files involved in open PRs was determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8).
With the list of files from the script in outstanding_files, the relevant commands were:
$ find src/libstd -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of most of the rest of libstd.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
Format libstd/sys with rustfmt
(Same strategy as #66691.)
This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd/sys *that are not involved in any currently open PR* to minimize merge conflicts. The list of files involved in open PRs was determined by querying GitHub's GraphQL API [with this script](https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8).
With the list of files from the script in outstanding_files, the relevant commands were:
$ find src/libstd/sys -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd/sys outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of most of the rest of the files.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
This commit applies rustfmt with rust-lang/rust's default settings to
files in src/libstd *that are not involved in any currently open PR* to
minimize merge conflicts. THe list of files involved in open PRs was
determined by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in outstanding_files, the
relevant commands were:
$ find src/libstd -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of libstd.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
This commit applies rustfmt with rust-lang/rust's default settings to
files in src/libstd/sys *that are not involved in any currently open PR*
to minimize merge conflicts. THe list of files involved in open PRs was
determined by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in outstanding_files, the
relevant commands were:
$ find src/libstd/sys -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd/sys outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of the files.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
This commit applies rustfmt with rust-lang/rust's default settings to
files in src/libstd/os *that are not involved in any currently open PR*
to minimize merge conflicts. THe list of files involved in open PRs was
determined by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in outstanding_files, the
relevant commands were:
$ find src/libstd/os -name '*.rs' \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ rg libstd/os outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of the files.
To confirm no funny business:
$ git checkout $THIS_COMMIT^
$ git show --pretty= --name-only $THIS_COMMIT \
| xargs rustfmt --edition=2018 --unstable-features --skip-children
$ git diff $THIS_COMMIT # there should be no difference
Panic machinery comments and tweaks
This is mostly more comments, but I also renamed some things:
* `BoxMeUp::box_me_up` is not terribly descriptive, and since this is a "take"-style method (the argument is `&mut self` but the return type is fully owned, even though you can't tell from the type) I chose a name involving "take".
* `continue_panic_fmt` was very confusing as it was entirely unclear what was being continued -- for some time I thought "continue" might be the same as "resume" for a panic, but that's something entirely different. So I renamed this to `begin_panic_handler`, matching the `begin_panic*` theme of the other entry points.
r? @Dylan-DPC @SimonSapin
Fallback to .init_array when no arguments are available on glibc Linux
Linux is one of the only platforms where `std::env::args` doesn't work in a cdylib.
