In doc examples, don't ignore read/write results
Calling `Read::read` or `Write::write` without checking the returned `usize` value is almost always an error. Example code in the documentation should demonstrate how to use the return value correctly. Otherwise, people might copy the example code thinking that it is okay to "fire and forget" these methods.
Improve the dbg! macro docs
# Description
As stated has been discussed in #58383 the docs do not clearly state why it is useful to have the option to use `dbg!` in release builds as well. This PR should change that.
closes#58383
This commit adds a new wasm32-based target distributed through rustup,
supported in the standard library, and implemented in the compiler. The
`wasm32-unknown-wasi` target is intended to be a WebAssembly target
which matches the [WASI proposal recently announced.][LINK]. In summary
the WASI target is an effort to define a standard set of syscalls for
WebAssembly modules, allowing WebAssembly modules to not only be
portable across architectures but also be portable across environments
implementing this standard set of system calls.
The wasi target in libstd is still somewhat bare bones. This PR does not
fill out the filesystem, networking, threads, etc. Instead it only
provides the most basic of integration with the wasi syscalls, enabling
features like:
* `Instant::now` and `SystemTime::now` work
* `env::args` is hooked up
* `env::vars` will look up environment variables
* `println!` will print to standard out
* `process::{exit, abort}` should be hooked up appropriately
None of these APIs can work natively on the `wasm32-unknown-unknown`
target, but with the assumption of the WASI set of syscalls we're able
to provide implementations of these syscalls that engines can implement.
Currently the primary engine implementing wasi is [wasmtime], but more
will surely emerge!
In terms of future development of libstd, I think this is something
we'll probably want to discuss. The purpose of the WASI target is to
provide a standardized set of syscalls, but it's *also* to provide a
standard C sysroot for compiling C/C++ programs. This means it's
intended that functions like `read` and `write` are implemented for this
target with a relatively standard definition and implementation. It's
unclear, therefore, how we want to expose file descriptors and how we'll
want to implement system primitives. For example should `std::fs::File`
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.
A `WasiFd` sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like `std::fs::File` if we bind wasi file
descriptors exactly.
Apart from the standard library, there's also the matter of how this
target is integrated with respect to its C standard library. The
reference sysroot, for example, provides managment of standard unix file
descriptors and also standard APIs like `open` (as opposed to the
relative `openat` inspiration for the wasi ssycalls). Currently the
standard library relies on the C sysroot symbols for operations such as
environment management, process exit, and `read`/`write` of stdio fds.
We want these operations in Rust to be interoperable with C if they're
used in the same process. Put another way, if Rust and C are linked into
the same WebAssembly binary they should work together, but that requires
that the same C standard library is used.
We also, however, want the `wasm32-unknown-wasi` target to be
usable-by-default with the Rust compiler without requiring a separate
toolchain to get downloaded and configured. With that in mind, there's
two modes of operation for the `wasm32-unknown-wasi` target:
1. By default the C standard library is statically provided inside of
`liblibc.rlib` distributed as part of the sysroot. This means that
you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're
good to go, a fully workable wasi binary pops out. This is
incompatible with linking in C code, however, which may be compiled
against a different sysroot than the Rust code was previously
compiled against. In this mode the default of `rust-lld` is used to
link binaries.
2. For linking with C code, the `-C target-feature=-crt-static` flag
needs to be passed. This takes inspiration from the musl target for
this flag, but the idea is that you're no longer using the provided
static C runtime, but rather one will be provided externally. This
flag is intended to also get coupled with an external `clang`
compiler configured with its own sysroot. Therefore you'll typically
use this flag with `-C linker=/path/to/clang-script-wrapper`. Using
this mode the Rust code will continue to reference standard C
symbols, but the definition will be pulled in by the linker configured.
Alright so that's all the current state of this PR. I suspect we'll
definitely want to discuss this before landing of course! This PR is
coupled with libc changes as well which I'll be posting shortly.
[LINK]:
[wasmtime]:
Calling `Read::read` or `Write::write` without checking the returned
`usize` value is almost always an error. Example code in the
documentation should demonstrate how to use the return value correctly.
Otherwise, people might copy the example code thinking that it is okay
to "fire and forget" these methods.
fs::copy() unix: set file mode early
A convenience method like fs::copy() should try to prevent pitfalls a
normal user doesn't think about.
In case of an empty umask, setting the file mode early prevents
temporarily world readable or even writeable files,
because the default mode is 0o666.
In case the target is a named pipe or special device node, setting the
file mode can lead to unwanted side effects, like setting permissons on
`/dev/stdout` or for root setting permissions on `/dev/null`.
copy_file_range() returns EINVAL, if the destination is a FIFO/pipe or
a device like "/dev/null", so fallback to io::copy, too.
Fixes: https://github.com/rust-lang/rust/issues/26933
Fixed: https://github.com/rust-lang/rust/issues/37885
Include id in Thread's Debug implementation
Since Rust 1.19.0, `id` is a stable method, so there is no reason to not include it in Debug implementation.
Add `Default` to `std::alloc::System`
`System` is a unit struct, thus, it can be constructed without any additional information. Therefore `Default` is a noop. However, in generic code, a `T: Default` may happen as in
```rust
#[derive(Default)]
struct Foo<A> {
allocator: A
}
```
Does this need a feature gate?
Should I also add `PartialEq/Eq/PartialOrd/Ord/Hash`?
Simplify checked_duration_since
This follows the same design as we updated to in #56490. Internally, all the system specific time implementations are checked, no panics. Then the panicking publicly exported API can just call the checked version of itself and make do with a single panic (`expect`) at the top.
Since the internal sys implementations are now checked, this gets rid of the extra `if self >= &earlier` check in `checked_duration_since`. Except likely making the generated machine code simpler, it also reduces the algorithm from "Check panic condition -> call possibly panicking method" to just "call non panicking method".
Added two test cases:
* Edge case: Make sure `checked_duration_since` on two equal `Instant`s produce a zero duration, not a `None`.
* Most common/intended usage: Make sure `later.checked_duration_since(earlier)`, returns an expected value.
SGX target: fix std unit tests
This fixes some tests and some code in the SGX sys implementation to make the `std` unit test suite pass.
#59009 must be merged first.
A convenience method like fs::copy() should try to prevent pitfalls a
normal user doesn't think about.
In case of an empty umask, setting the file mode early prevents
temporarily world readable or even writeable files,
because the default mode is 0o666.
In case the target is a named pipe or special device node, setting the
file mode can lead to unwanted side effects, like setting permissons on
`/dev/stdout` or for root setting permissions on `/dev/null`.
copy_file_range() returns EINVAL, if the destination is a FIFO/pipe or
a device like "/dev/null", so fallback to io::copy, too.
Use `fcopyfile` on MacOS instead of `copyfile`.
Fixes: https://github.com/rust-lang/rust/issues/26933
Fixed: https://github.com/rust-lang/rust/issues/37885
Rollup of 18 pull requests
Successful merges:
- #59106 (Add peer_addr function to UdpSocket)
- #59170 (Add const generics to rustdoc)
- #59172 (Update and clean up several parts of CONTRIBUTING.md)
- #59190 (consistent naming for Rhs type parameter in libcore/ops)
- #59236 (Rename miri component to miri-preview)
- #59266 (Do not complain about non-existing fields after parse recovery)
- #59273 (some small HIR doc improvements)
- #59291 (Make Option<ThreadId> no larger than ThreadId, with NonZeroU64)
- #59297 (convert field/method confusion help to suggestions)
- #59304 (Move some bench tests back from libtest)
- #59309 (Add messages for different verbosity levels. Output copy actions.)
- #59321 (Unify E0109, E0110 and E0111)
- #59322 (Tweak incorrect escaped char diagnostic)
- #59323 (use suggestions for "enum instead of variant" error)
- #59327 (Add NAN test to docs)
- #59329 (cleanup: Remove compile-fail-fulldeps directory again)
- #59347 (Move one test from run-make-fulldeps to ui)
- #59360 (Add tracking issue number for `seek_convenience`)
Failed merges:
r? @ghost
Add peer_addr function to UdpSocket
Fixes#59104
This is my first pull request to Rust, so opening early for some feedback.
My biggest question is: where do I add tests?
Any comments very much appreciated!
