| Age | Commit message (Collapse) | Author | Lines |
|---|
|
PR https://github.com/rust-lang/rust/pull/66512 added the ability to set argv[0] on
Command. As a side effect, it changed the Debug output to print both the program and
argv[0], which in practice results in stuttery output ("echo echo foo").
This PR reverts the behaviour to the the old one, so that the command is only printed
once - unless arg0 has been set. In that case it emits "[command] arg0 arg1 ...".
|
|
Delete flaky test net::tcp::tests::fast_rebind
This test is unreliable for at least 3 users on two platforms: see #57509 and #51006. It was added 5 years ago in #22015. Do we know whether this is testing something important that would indicate a bug in our implementation, or if it's fine to remove?
r? @sfackler @alexcrichton because this somewhat resembles #59018
Closes #57509. Closes #51006.
|
|
Fix example code of OpenOptions::open
The example didn't set the access mode flag, which resulted in an `Err(InvalidInput)`.
r? @steveklabnik
|
|
Fix signature of `__wasilibc_find_relpath`
Looks like this function changed upstream, so it needs to be adjusted
for when used by libstd.
|
|
|
|
r=centril
Revert stabilization of never type
Fixes https://github.com/rust-lang/rust/issues/66757
I decided to keep the separate `never-type-fallback` feature gate, but tried to otherwise revert https://github.com/rust-lang/rust/pull/65355. Seemed pretty clean.
( cc @Centril, author of #65355, you may want to check this over briefly )
|
|
This reverts commit 15c30ddd69d6cc3fffe6d304c6dc968a5ed046f1.
|
|
This reverts commit 089229a1935fa9795cfdefa518c8f8c3beb66db8.
|
|
Require stable/unstable annotations for the constness of all stable fns with a const modifier
r? @RalfJung @Centril
Every `#[stable]` const fn now needs either a `#[rustc_const_unstable]` attribute or a `#[rustc_const_stable]` attribute. You can't silently stabilize the constness of a function anymore.
|
|
SGX: Change ELF entrypoint
This fixes [rust-sgx issue #148](https://github.com/fortanix/rust-sgx/issues/148).
A new entry point is created for the ELF file generated by `rustc`, separate from the enclave entry point. When the ELF file is executed as a Linux binary, the error message below is written to stderr.
> Error: This file is an SGX enclave which cannot be executed as a standard Linux binary.
> See the installation guide at https://edp.fortanix.com/docs/installation/guide/ on how to use 'cargo run' or follow the steps at https://edp.fortanix.com/docs/tasks/deployment/ for manual deployment.
When the ELF file is converted to an SGXS using `elf2sgxs`, the old entry point is still set as the enclave entry point. In a future pull request in the rust-sgx repository, `elf2sgxs` will be modified to remove the code in the ELF entry point, since this code is not needed in the enclave.
|
|
|
|
functions with a `const` modifier
|
|
|
|
Looks like this function changed upstream, so it needs to be adjusted
for when used by libstd.
|
|
Remove irelevant comment on `register_dtor`
Fixes #66572.
|
|
davidtwco:issue-64130-async-send-sync-error-improvements, r=nikomatsakis
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
|
|
lookup' algorithms
|
|
|
|
remove dependency from libhermit
The build process of the unikernel HermitCore is redesigned and doesn't longer depend on libhermit.
|
|
Signed-off-by: David Wood <david@davidtw.co>
|
|
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.
|
|
get rid of __ in field names
This old work-around should not be needed any more.
|
|
|
|
Remove boxed closures in address parser.
Simplify address parser by removing unnecessary boxed closures.
Also relevant for https://github.com/rust-lang/rfcs/pull/2832.
|
|
Simplify {IoSlice, IoSliceMut}::advance examples and tests
Remove unnecessary calls to `std::mem::replace` and make variables immutable.
|
|
Modified the testcases for VxWorks
|
|
|
|
syscall itself
|
|
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.
|
|
add ExitStatusExt into prelude
r? @alexcrichton
|
|
VxWorks: fix issues in accessing environment variables
|
|
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.
|
|
|
|
Remove unnecessary calls to `std::mem::replace` and make variables immutable.
|
|
entry point
|
|
|
|
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.
|
|
Adding docs for keyword match, move
Partial fix of issue #34601.
|
|
|
|
Replace .unwrap() with ? in std::os::unix::net
As people like to copy examples, this gives them good habits.
|
|
|
|
|
|
|
|
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.
|
