unbreak openbsd/bitrig build
- remove `pub` from `struct` (error: visibility has no effect inside functions)
- move `pthread_main_np` into function
r? @alexcrichton
Require braces when a closure has an explicit return type. This is a [breaking-change]: instead of a closure like `|| -> i32 22`, prefer `|| -> i32 { 22 }`.
Fixes#23420.
The IP and socket address types all had `FromStr` implemented but the
implementations were not marked stable, nor was the error type returned ready to
be properly stabilized.
This commit marks the implementations of `FromStr` as stable and also renamed
the `ParseError` structure to `AddrParseError`. The error is now also an opaque
structure that cannot be constructed outside the standard library.
cc #22949
[breaking-change]
Nothing inside of the read/write interface itself can panic, so any
poison must have been the result of user code which the lock isn't
protecting.
This seems safe to me, but if we don't want to go this route we should update the docs to indicate that these methods can panic.
r? @alexcrichton
This commit stabilizes the `cloned` iterator after tweaking the signature to
require that the iterator is over `&T` instead of `U: Deref<T>`. This method has
had time to bake for awhile now and it's not clear whether the `Deref` bound is
worth it. Additionally, there aren't clear conventions on when to bound and/or
implement the `Deref` trait, so for now the conservative route is to require
references instead of `U: Deref<T>`.
To change this signature to using `Deref` would technically be a
backwards-incompatible change, but it is doubtful that any code will actually
break in practice.
Hopefully didn’t miss or mess up anything.
~~EDIT: ah, as usual, just didn’t bother running build before pushing a submit request button. Build pending.~~
* no_split_stack was renamed to no_stack_check
* deriving was renamed to derive
* `use foo::mod` was renamed to `use foo::self`;
* legacy lifetime definitions in closures have been replaced with `for` syntax
* `fn foo() -> &A + B` has been deprecated for some time (needs parens)
* Obsolete `for Sized?` syntax
* Obsolete `Sized? Foo` syntax
* Obsolete `|T| -> U` syntax
* rustdoc was doubly appending the file name to the path of where to
generate the source files, meanwhile, the [src] hyperlinks were not
* Added a flag to rustdoc::html::render::clean_srcpath to ignore the
last path component, i.e. the file name itself to prevent the issue
* This also avoids creating directories with the same name as source
files, and it makes sure the link to `main.css` is correct as well.
* Added regression tests to ensure the rustdoc heirarchy of rendered
source files remains consistent
Fixes#23192
This trait has proven quite useful when defining marker traits to avoid the
semi-confusing `PhantomFn` trait and it looks like it will continue to be a
useful tool for defining these traits.
I often have to run `ast-json` or look into the pretty-printer source to figure out what the fields of an AST enum mean. I've tried to document most of what I know (and some semi-obvious stuff).
r? @steveklabnik
f? @eddyb
The alignment field is actually a \"pointer sized\" type instead of always i64,
requiring that the size of the padding field is also calculated slightly
differently.
Closes#23425
Very minor fix: in `std::net::Ipv6Addr::new`, the documentation had an incomplete representation of the resulting address, missing the last two groups.
This commit clarifies some of the unstable features in the `str` module by
moving them out of the blanket `core` and `collections` features.
The following methods were moved to the `str_char` feature which generally
encompasses decoding specific characters from a `str` and dealing with the
result. It is unclear if any of these methods need to be stabilized for 1.0 and
the most conservative route for now is to continue providing them but to leave
them as unstable under a more specific name.
* `is_char_boundary`
* `char_at`
* `char_range_at`
* `char_at_reverse`
* `char_range_at_reverse`
* `slice_shift_char`
The following methods were moved into the generic `unicode` feature as they are
specifically enabled by the `unicode` crate itself.
* `nfd_chars`
* `nfkd_chars`
* `nfc_chars`
* `graphemes`
* `grapheme_indices`
* `width`
This patch changes the type of byte string literals from `&[u8]` to `&[u8; N]`.
It also implements some necessary traits (`IntoBytes`, `Seek`, `Read`, `BufRead`) for fixed-size arrays (also related to #21725) and adds test for #17233, which seems to be resolved.
Fixes#18465
[breaking-change]
Safe fns are no longer subtypes of unsafe fns, but you can coerce from one to the other.
This is a [breaking-change] in that impl fns must now be declared `unsafe` if the trait is declared `unsafe`. In some rare cases, the subtyping change may also direct affect you, but no such cases were encountered in practice.
Fixes#23449.
r? @nrc
This commit stabilizes the `cloned` iterator after tweaking the signature to
require that the iterator is over `&T` instead of `U: Deref<T>`. This method has
had time to bake for awhile now and it's not clear whether the `Deref` bound is
worth it. Additionally, there aren't clear conventions on when to bound and/or
implement the `Deref` trait, so for now the conservative route is to require
references instead of `U: Deref<T>`.
To change this signature to using `Deref` would technically be a
backwards-incompatible change, but it is doubtful that any code will actually
break in practice.
This commit clarifies some of the unstable features in the `str` module by
moving them out of the blanket `core` and `collections` features.
The following methods were moved to the `str_char` feature which generally
encompasses decoding specific characters from a `str` and dealing with the
result. It is unclear if any of these methods need to be stabilized for 1.0 and
the most conservative route for now is to continue providing them but to leave
them as unstable under a more specific name.
* `is_char_boundary`
* `char_at`
* `char_range_at`
* `char_at_reverse`
* `char_range_at_reverse`
* `slice_shift_char`
The following methods were moved into the generic `unicode` feature as they are
specifically enabled by the `unicode` crate itself.
* `nfd_chars`
* `nfkd_chars`
* `nfc_chars`
* `graphemes`
* `grapheme_indices`
* `width`
Final remnant of reflection is gone. Also, virtual `Trait` destructors are no longer tied to `Box`.
That means they can be used to drop any instance of the type (used in libarena to replace TyDesc).
This is [breaking-change] for direct users of intrinsics:
* use `intrinsics::type_name::<T>()` instead of `(*intrinsics::get_tydesc::<T>()).name`
* the only way to get the destructor is from a trait object's vtable (see libarena changes)
r? @pcwalton f? @dotdash
The alignment field is actually a "pointer sized" type instead of always i64,
requiring that the size of the padding field is also calculated slightly
differently.
Closes#23425
This function is the current replacement for `std::old_io::timer` which will
soon be deprecated. This function is unstable and has its own feature gate as it
does not yet have an RFC nor has it existed for very long.
These two borrowing examples were confusing/misleading. This changes it
to more clearly show how you _can_ borrow a box, and also uses & instead
of &*.
This function is the current replacement for `std::old_io::timer` which will
soon be deprecated. This function is unstable and has its own feature gate as it
does not yet have an RFC nor has it existed for very long.
Very minor fix: in `std::net::Ipv6Addr::new`, the documentation had an incomplete representation of the resulting address, missing the last two groups.
This upcast coercion currently never requires vtable changes. It should be generalized.
This is a [breaking-change] -- if you have an impl on an object type like `impl SomeTrait`, then this will no longer be applicable to object types like `SomeTrait+Send`. In the standard library, this primarily affected `Any`, and this PR adds impls for `Any+Send` as to keep the API the same in practice. An alternate workaround is to use UFCS form or standalone fns. For more details, see <https://github.com/rust-lang/rust/issues/18737#issuecomment-78450798>.
r? @nrc
This upcast coercion currently preserves the vtable for the object, but
eventually it can be used to create a derived vtable. The upcast
coercion is not introduced into method dispatch; see comment on #18737
for information about why. Fixes#18737.
This looks like the most logical target to give to this link, or at least what I would expect as someone that want to integrate with a native library.
r? @steveklabnik
The [associated RFC][rfc] for possibly splitting out `flush` has been closed and
as a result there are no more blockers for stabilizing this method, so this
commit marks the method as such.
[rfc]: https://github.com/rust-lang/rfcs/pull/950
To the correct MAP_NORESERVE. Every other instance is known as MAP_NORESERVE, so this is just a basic typo.
I really doubt this will break anybody's but my own code.
[breaking-change]
This removes the error case of the compression functions, the only errors that
can occur are incorrect parameters or an out-of-memory condition, both of which
are handled with panics in Rust.
Also introduces an extensible `Error` type instead of returning an `Option`.
The type implements a destructor so you can't destructure it.
- Allow inherent implementations on `char`, `str`, `[T]`, `*const T`, `*mut T` and all the numeric primitives.
- copy `unicode::char::CharExt` methods into `impl char`
- remove `unicode::char::CharExt`, its re-export `std::char::CharExt` and `CharExt` from the prelude
- copy `collections::str::StrExt` methods into `impl str`
- remove `collections::str::StrExt` its re-export `std::str::StrExt`, and `StrExt` from the prelude
- copy `collections::slice::SliceExt` methods into `impl<T> [T]`
- remove `collections::slice::SliceExt` its re-export `std::slice::SliceExt`, and `SliceExt` from the prelude
- copy `core::ptr::PtrExt` methods into `impl<T> *const T`
- remove `core::ptr::PtrExt` its re-export `std::ptr::PtrExt`, and `PtrExt` from the prelude
- copy `core::ptr::PtrExt` and `core::ptr::MutPtrExt` methods into `impl<T> *mut T`
- remove `core::ptr::MutPtrExt` its re-export `std::ptr::MutPtrExt`, and `MutPtrExt` from the prelude
- copy `core::num::Int` and `core::num::SignedInt` methods into `impl i{8,16,32,64,size}`
- copy `core::num::Int` and `core::num::UnsignedInt` methods into `impl u{8,16,32,64,size}`
- remove `core::num::UnsignedInt` and its re-export `std::num::UnsignedInt`
- move `collections` tests into its own crate: `collectionstest`
- copy `core::num::Float` methods into `impl f{32,64}`
Because this PR removes several traits, this is a [breaking-change], however functionality remains unchanged and breakage due to unresolved imports should be minimal. If you encounter an error due to an unresolved import, simply remove the import:
``` diff
fn main() {
- use std::num::UnsignedInt; //~ error: unresolved import `std::num::UnsignedInt`.
-
println!("{}", 8_usize.is_power_of_two());
}
```
---
cc #16862
[preview docs](http://japaric.github.io/inherent/std/index.html)
[unicode::char](http://japaric.github.io/inherent/unicode/primitive.char.html)
[collections::str](http://japaric.github.io/inherent/collections/primitive.str.html)
[std::f32](http://japaric.github.io/inherent/std/primitive.f32.html)
This commit performs a stabilization pass over the std::net module,
incorporating the changes from RFC 923. Specifically, the following actions were
taken:
Stable functionality:
* `net` (the name)
* `Shutdown`
* `Shutdown::{Read, Write, Both}`
* `lookup_host`
* `LookupHost`
* `SocketAddr`
* `SocketAddr::{V4, V6}`
* `SocketAddr::port`
* `SocketAddrV4`
* `SocketAddrV4::{new, ip, port}`
* `SocketAddrV6`
* `SocketAddrV4::{new, ip, port, flowinfo, scope_id}`
* Common trait impls for socket addr structures
* `ToSocketAddrs`
* `ToSocketAddrs::Iter`
* `ToSocketAddrs::to_socket_addrs`
* `ToSocketAddrs for {SocketAddr*, (Ipv*Addr, u16), str, (str, u16)}`
* `Ipv4Addr`
* `Ipv4Addr::{new, octets, to_ipv6_compatible, to_ipv6_mapped}`
* `Ipv6Addr`
* `Ipv6Addr::{new, segments, to_ipv4}`
* `TcpStream`
* `TcpStream::connect`
* `TcpStream::{peer_addr, local_addr, shutdown, try_clone}`
* `{Read,Write} for {TcpStream, &TcpStream}`
* `TcpListener`
* `TcpListener::bind`
* `TcpListener::{local_addr, try_clone, accept, incoming}`
* `Incoming`
* `UdpSocket`
* `UdpSocket::bind`
* `UdpSocket::{recv_from, send_to, local_addr, try_clone}`
Unstable functionality:
* Extra methods on `Ipv{4,6}Addr` for various methods of inspecting the address
and determining qualities of it.
* Extra methods on `TcpStream` to configure various protocol options.
* Extra methods on `UdpSocket` to configure various protocol options.
Deprecated functionality:
* The `socket_addr` method has been renamed to `local_addr`
This commit is a breaking change due to the restructuring of the `SocketAddr`
type as well as the renaming of the `socket_addr` method. Migration should be
fairly straightforward, however, after accounting for the new level of
abstraction in `SocketAddr` (protocol distinction at the socket address level,
not the IP address).
[breaking-change]
Most of the changes are cleanup facilitated by straight-forward attribute handling.
This is a minor [breaking-change] for users of `quote_stmt!` (returns `Option<P<Stmt>>` now) and some of the public methods in `Parser` (a few `Vec<Attribute>` arguments/returns were removed).
r? @nikomatsakis
This looks like the most logical target to give to this link, or at least what I would expect as someone that want to integrate with a native library.
r? @steveklabnik
The [associated RFC][rfc] for possibly splitting out `flush` has been closed and
as a result there are no more blockers for stabilizing this method, so this
commit marks the method as such.
[rfc]: https://github.com/rust-lang/rfcs/pull/950
This removes the error case of the compression functions, the only errors that
can occur are incorrect parameters or an out-of-memory condition, both of which
are handled with panics in Rust.
Also introduces an extensible `Error` type instead of returning an `Option`.
This commit deprecates the `count`, `range` and `range_step` functions
in `iter`, in favor of range notation. To recover all existing
functionality, a new `step_by` adapter is provided directly on `ops::Range`
and `ops::RangeFrom`.
[breaking-change]
r? @alexcrichton
To the correct MAP_NORESERVE. Every other thing is known as MAP_NORESERVE, so this is just a basic typo.
I really doubt this will break anybody's but my own code.
r? @alexcrichton or @aturon
This still needs to somehow figure out how to avoid unstable warnings arising from the use of unstable functions. I tried to use `#[allow_internal_unstable]` but it still spits out warnings as far as I can see. @huonw (I think you implemented it) does `#[allow_internal_unstable]` not work for some reason or am I using it incorrectly?
This commit starts to organize the `std::os::$platform` modules and in the
process stabilizes some of the functionality contained within. The organization
of these modules will reflect the organization of the standard library itself
with extension traits for primitives in the same corresponding module.
The OS-specific modules will grow more functionality over time including
concrete types that are not extending functionality of other structures, and
these will either go into the closest module in `std::os::$platform` or they
will grow a new module in the hierarchy.
The following items are now stable:
* `os::{unix, windows}`
* `unix::ffi`
* `unix::ffi::OsStrExt`
* `unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}`
* `unix::ffi::OsString`
* `unix::ffi::OsStringExt::{from_vec, into_vec}`
* `unix::process`
* `unix::process::CommandExt`
* `unix::process::CommandExt::{uid, gid}`
* `unix::process::ExitStatusExt`
* `unix::process::ExitStatusExt::signal`
* `unix::prelude`
* `windows::ffi`
* `windows::ffi::OsStringExt`
* `windows::ffi::OsStringExt::from_wide`
* `windows::ffi::OsStrExt`
* `windows::ffi::OsStrExt::encode_wide`
* `windows::prelude`
The following items remain unstable:
* `unix::io`
* `unix::io::{Fd, AsRawFd}`
* `unix::fs::{PermissionsExt, OpenOptionsExt}`
* `windows::io`
* `windows::io::{Handle, AsRawHandle}`
* `windows::io::{Socket, AsRawSocket}`
* `windows::fs`
* `windows::fs::OpenOptionsExt`
Due to the reorgnization of the platform extension modules, this commit is a
breaking change. Most imports can be fixed by adding the relevant libstd module
in the `use` path (such as `ffi` or `fs`).
[breaking-change]
This commit starts to organize the `std::os::$platform` modules and in the
process stabilizes some of the functionality contained within. The organization
of these modules will reflect the organization of the standard library itself
with extension traits for primitives in the same corresponding module.
The OS-specific modules will grow more functionality over time including
concrete types that are not extending functionality of other structures, and
these will either go into the closest module in `std::os::$platform` or they
will grow a new module in the hierarchy.
The following items are now stable:
* `os::{unix, windows}`
* `unix::ffi`
* `unix::ffi::OsStrExt`
* `unix::ffi::OsStrExt::{from_bytes, as_bytes, to_cstring}`
* `unix::ffi::OsString`
* `unix::ffi::OsStringExt::{from_vec, into_vec}`
* `unix::process`
* `unix::process::CommandExt`
* `unix::process::CommandExt::{uid, gid}`
* `unix::process::ExitStatusExt`
* `unix::process::ExitStatusExt::signal`
* `unix::prelude`
* `windows::ffi`
* `windows::ffi::OsStringExt`
* `windows::ffi::OsStringExt::from_wide`
* `windows::ffi::OsStrExt`
* `windows::ffi::OsStrExt::encode_wide`
* `windows::prelude`
The following items remain unstable:
* `unix::io`
* `unix::io::{Fd, AsRawFd}`
* `unix::fs::{PermissionsExt, OpenOptionsExt}`
* `windows::io`
* `windows::io::{Handle, AsRawHandle}`
* `windows::io::{Socket, AsRawSocket}`
* `windows::fs`
* `windows::fs::OpenOptionsExt`
Due to the reorgnization of the platform extension modules, this commit is a
breaking change. Most imports can be fixed by adding the relevant libstd module
in the `use` path (such as `ffi` or `fs`).
[breaking-change]
`std::io` does not currently expose the `stdin_raw`, `stdout_raw`, or
`stderr_raw` functions. According to the current plans for stdio (see
rust-lang/rfcs#517), raw access will likely be provided using the
platform-specific `std::os::{unix,windows}` modules. At the moment we
don't expose any way to do this. As such, delete all mention of the
`*_raw` functions from the `stdin`/`stdout`/`stderr` function
documentation.
While we're at it, remove a few `pub`s from items that aren't exposed.
This is done just to lessen the confusion experienced by anyone who
looks at the source in an attempt to find the `*_raw` functions.
It is a frequent pattern among I/O functions to take `P: AsPath + ?Sized` or
`AsOsStr` instead of `AsPath`. Most of these functions do not need to take
ownership of their argument, but for libraries in general it's much more
ergonomic to not deal with `?Sized` at all and simply require an argument `P`
instead of `&P`.
This change is aimed at removing unsightly `?Sized` bounds while retaining the
same level of usability as before. All affected functions now take ownership of
their arguments instead of taking them by reference, but due to the forwarding
implementations of `AsOsStr` and `AsPath` all code should continue to work as it
did before.
This is strictly speaking a breaking change due to the signatures of these
functions changing, but normal idiomatic usage of these APIs should not break in
practice.
[breaking-change]
Recent changes in path semantics meant that if none of the components in a
relative path existed as a part of a call to `create_dir_all` then the call
would fail as `create_dir("")` would be attempted and would fail with an OS
error.
It is a frequent pattern among I/O functions to take `P: AsPath + ?Sized` or
`AsOsStr` instead of `AsPath`. Most of these functions do not need to take
ownership of their argument, but for libraries in general it's much more
ergonomic to not deal with `?Sized` at all and simply require an argument `P`
instead of `&P`.
This change is aimed at removing unsightly `?Sized` bounds while retaining the
same level of usability as before. All affected functions now take ownership of
their arguments instead of taking them by reference, but due to the forwarding
implementations of `AsOsStr` and `AsPath` all code should continue to work as it
did before.
This is strictly speaking a breaking change due to the signatures of these
functions changing, but normal idiomatic usage of these APIs should not break in
practice.
[breaking-change]
LLVM older that 3.6 has a bug that cause assertions when compiling certain
constructs. For 3.5 there's still a chance that the bug might get fixed
in 3.5.2, so let's keep allowing to compile with it for it for now.
Previously it would fail on a trivial case like
/// Summary line
/// <trailing space>
/// Regular content
Compliant markdown preprocessor would render that as two separate paragraphs, but our summary line
extractor interprets both lines as the same paragraph and includes both into the short summary resulting in
Previously it would fail on a trivial case like
/// Summary line
/// <trailing space>
/// Regular content
Compliant markdown preprocessor would render that as two separate paragraphs, but our summary line
extractor interprets both lines as the same paragraph and includes both into the short summary resulting in
std::io does not currently expose the stdin_raw, stdout_raw, or
stderr_raw functions. According to the current plans for stdio (see RFC
#517), raw access will likely be provided using the platform-specific
std::os::{unix,windows} modules. At the moment we don't expose any way
to do this. As such, delete all mention of the _raw functions from the
stdin/stdout/stderr function documentation.
While we're at it, remove a few `pub`s from items that aren't exposed.
This is done just to lessen the confusion experienced by anyone who
looks at the source in an attempt to find the _raw functions.
This adds search by type (for functions/methods) support to Rustdoc. Target issue is at https://github.com/rust-lang/rfcs/issues/658.
I've described my approach here: https://github.com/rust-lang/rfcs/issues/658#issuecomment-76484200. I'll copy the text in here as well:
---
Hi, it took me longer than I wished, but I have implemented this in a not-too-complex way that I think can be extended to support more complex features (like the ones mentioned [here](https://github.com/rust-lang/rust/issues/12866#issuecomment-66945317)).
The idea is to generate a JSON representation of the types of methods/functions in the existing index, and then make the JS understand when it should look by type (and not by name).
I tried to come up with a JSON representation that can be extended to support generics, bounds, ref/mut annotations and so on. Here are a few samples:
Function:
```rust
fn to_uppercase(c: char) -> char
```
```json
{
"inputs": [
{"name": "char"}
],
"output": {
"name": "char",
}
}
```
Method (implemented or defined in trait):
```rust
// in struct Vec
// self is considered an argument as well
fn capacity(&self) -> usize
```
```json
{
"inputs": [
{"name": "vec"}
],
"output": {
"name": "usize"
}
}
```
This simple format can be extended by adding more fields, like `generic: bool`, a `bounds` mapping and so on.
I have a working implementation in https://github.com/rust-lang/rust/compare/master...mihneadb:rustdoc-search-by-type. You can check out a live demo [here](http://data.mihneadb.net/doc/std/index.html?search=charext%20-%3E%20char).
The feature list is not that long:
- search by types (you *can* use generics as well, as long as you use the exact name - e.g. [`vec,t -> `](http://data.mihneadb.net/doc/std/index.html?search=vec%2C%20t%20-%3E))
- order of arguments does not matter
- `self` is took into account as well (e.g. search for `vec -> usize`)
- does not use "complex" annotations (e.g. you don't search for `&char -> char` but for `char -> char`)
My goal is to get a working, minimal "base" merged so that others can build upon it. How should I proceed? Do I open a PR (badly in need of code review since this is my first non "hello world"-ish rust code)?
---
In case that there is a destination for the array, like in
"let x = [expr; n]", we currently don't evaluate the given expression if
n is zero. That's inconsistent with all other cases, including "[expr;
0]" without a destination.
Fixes#23354
LLVM older that 3.6 has a bug that cause assertions when compiling certain
constructs. For 3.5 there's still a chance that the bug might get fixed
in 3.5.2, so let's keep allowing to compile with it for it for now.
Previously it would fail on a trivial case like
/// Summary line
/// <trailing space>
/// Regular content
Compliant markdown preprocessor would render that as two separate paragraphs, but our summary line
extractor would interpret both lines as the same paragraph and include both into the short summary.
at least that's what the docs say: http://doc.rust-lang.org/std/slice/fn.from_raw_parts.html
A few situations got prettier. In some situations the mutability of the resulting and source pointers differed (and was cast away by transmute), the mutability matches now.
It wasn't clear to me that early_error was correct here, but it seems to
work. This code is reachable from `rustdoc`, which is problematic, because
early_error panics. rustc handles the panics gracefully (without ICEing or
crashing), but rustdoc does not. It's not the first such rustdoc problem,
though:
$ rustdoc hello.rs --extern std=bad-std
error: extern location for std does not exist: bad-std
hello.rs:1:1: 1:1 error: can't find crate for `std`
hello.rs:1
^
error: aborting due to 2 previous errors
thread '<unnamed>' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libsyntax/diagnostic.rs:151
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "rustc failed"', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/result.rs:744
thread '<main>' panicked at 'child thread None panicked', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/thread.rs:661
Reduce code size overhead from core::panicking::panic
core::panicking::panic currently creates an Arguments structure using
format_args!("{}", expr), which formats the expr str using the Display::fmt.
Display::fmt pulls in Formatter::pad, which then also pulls in string-related
code for truncation and padding.
If core::panicking::panic instead creates an Arguments structure with a string
piece, it is possible that the Display::fmt function for str can be optimized
out of the program.
In my testing with a 32-bit x86 bare metal program, the change tended to save
between ~100 bytes and ~5500 bytes, depending on what other panic* functions
the program invokes and whether the panic_fmt lang item uses the Arguments
value.
This commit performs a stabilization pass over the std::net module,
incorporating the changes from RFC 923. Specifically, the following actions were
taken:
Stable functionality:
* `net` (the name)
* `Shutdown`
* `Shutdown::{Read, Write, Both}`
* `lookup_host`
* `LookupHost`
* `SocketAddr`
* `SocketAddr::{V4, V6}`
* `SocketAddr::port`
* `SocketAddrV4`
* `SocketAddrV4::{new, ip, port}`
* `SocketAddrV6`
* `SocketAddrV4::{new, ip, port, flowinfo, scope_id}`
* Common trait impls for socket addr structures
* `ToSocketAddrs`
* `ToSocketAddrs::Iter`
* `ToSocketAddrs::to_socket_addrs`
* `ToSocketAddrs for {SocketAddr*, (Ipv*Addr, u16), str, (str, u16)}`
* `Ipv4Addr`
* `Ipv4Addr::{new, octets, to_ipv6_compatible, to_ipv6_mapped}`
* `Ipv6Addr`
* `Ipv6Addr::{new, segments, to_ipv4}`
* `TcpStream`
* `TcpStream::connect`
* `TcpStream::{peer_addr, local_addr, shutdown, try_clone}`
* `{Read,Write} for {TcpStream, &TcpStream}`
* `TcpListener`
* `TcpListener::bind`
* `TcpListener::{local_addr, try_clone, accept, incoming}`
* `Incoming`
* `UdpSocket`
* `UdpSocket::bind`
* `UdpSocket::{recv_from, send_to, local_addr, try_clone}`
Unstable functionality:
* Extra methods on `Ipv{4,6}Addr` for various methods of inspecting the address
and determining qualities of it.
* Extra methods on `TcpStream` to configure various protocol options.
* Extra methods on `UdpSocket` to configure various protocol options.
Deprecated functionality:
* The `socket_addr` method has been renamed to `local_addr`
This commit is a breaking change due to the restructuring of the `SocketAddr`
type as well as the renaming of the `socket_addr` method. Migration should be
fairly straightforward, however, after accounting for the new level of
abstraction in `SocketAddr` (protocol distinction at the socket address level,
not the IP address).
[breaking-change]
This commit deprecates the `count`, `range` and `range_step` functions
in `iter`, in favor of range notation. To recover all existing
functionality, a new `step_by` adapter is provided directly on `ops::Range`
and `ops::RangeFrom`.
[breaking-change]
The new `std::io` module has had some time to bake now, and this commit
stabilizes its functionality. There are still portions of the module which
remain unstable, and below contains a summart of the actions taken.
This commit also deprecates the entire contents of the `old_io` module in a
blanket fashion. All APIs should now have a reasonable replacement in the
new I/O modules.
Stable APIs:
* `std::io` (the name)
* `std::io::prelude` (the name)
* `Read`
* `Read::read`
* `Read::{read_to_end, read_to_string}` after being modified to return a `usize`
for the number of bytes read.
* `ReadExt`
* `Write`
* `Write::write`
* `Write::{write_all, write_fmt}`
* `WriteExt`
* `BufRead`
* `BufRead::{fill_buf, consume}`
* `BufRead::{read_line, read_until}` after being modified to return a `usize`
for the number of bytes read.
* `BufReadExt`
* `BufReader`
* `BufReader::{new, with_capacity}`
* `BufReader::{get_ref, get_mut, into_inner}`
* `{Read,BufRead} for BufReader`
* `BufWriter`
* `BufWriter::{new, with_capacity}`
* `BufWriter::{get_ref, get_mut, into_inner}`
* `Write for BufWriter`
* `IntoInnerError`
* `IntoInnerError::{error, into_inner}`
* `{Error,Display} for IntoInnerError`
* `LineWriter`
* `LineWriter::{new, with_capacity}` - `with_capacity` was added
* `LineWriter::{get_ref, get_mut, into_inner}` - `get_mut` was added)
* `Write for LineWriter`
* `BufStream`
* `BufStream::{new, with_capacities}`
* `BufStream::{get_ref, get_mut, into_inner}`
* `{BufRead,Read,Write} for BufStream`
* `stdin`
* `Stdin`
* `Stdin::lock`
* `Stdin::read_line` - added method
* `StdinLock`
* `Read for Stdin`
* `{Read,BufRead} for StdinLock`
* `stdout`
* `Stdout`
* `Stdout::lock`
* `StdoutLock`
* `Write for Stdout`
* `Write for StdoutLock`
* `stderr`
* `Stderr`
* `Stderr::lock`
* `StderrLock`
* `Write for Stderr`
* `Write for StderrLock`
* `io::Result`
* `io::Error`
* `io::Error::last_os_error`
* `{Display, Error} for Error`
Unstable APIs:
(reasons can be found in the commit itself)
* `Write::flush`
* `Seek`
* `ErrorKind`
* `Error::new`
* `Error::from_os_error`
* `Error::kind`
Deprecated APIs
* `Error::description` - available via the `Error` trait
* `Error::detail` - available via the `Display` implementation
* `thread::Builder::{stdout, stderr}`
Changes in functionality:
* `old_io::stdio::set_stderr` is now a noop as the infrastructure for printing
backtraces has migrated to `std::io`.
[breaking-change]
This implements a wish suggested in #17410, detecting enum variants that are never constructed, even in the presence of `#[derive(Clone)]`. The implementation is general and not specific to `#[derive(Clone)]`.
r? @jakub-
When this attribute is applied to a function, its return value gets the
noalias attribute, which is how you tell LLVM that the function returns
a \"new\" pointer that doesn't alias anything accessible to the caller,
i.e. it acts like a memory allocator.
Plain malloc doesn't need this attribute because LLVM already knows
about malloc and adds the attribute itself.
Show how to get a pointer without destroying the box.
Use `boxed::into_raw` instead of `mem::transmute`.
I removed the `let my_num: *const i32 = mem::transmute(my_num);` case altogether because we own the box, a `*mut` pointer is good anywhere a `*const` is needed, `from_raw` takes a mutable pointer and casting from a `*const` caused an ICE.
The new `std::io` module has had some time to bake now, and this commit
stabilizes its functionality. There are still portions of the module which
remain unstable, and below contains a summart of the actions taken.
This commit also deprecates the entire contents of the `old_io` module in a
blanket fashion. All APIs should now have a reasonable replacement in the
new I/O modules.
Stable APIs:
* `std::io` (the name)
* `std::io::prelude` (the name)
* `Read`
* `Read::read`
* `Read::{read_to_end, read_to_string}` after being modified to return a `usize`
for the number of bytes read.
* `Write`
* `Write::write`
* `Write::{write_all, write_fmt}`
* `BufRead`
* `BufRead::{fill_buf, consume}`
* `BufRead::{read_line, read_until}` after being modified to return a `usize`
for the number of bytes read.
* `BufReader`
* `BufReader::{new, with_capacity}`
* `BufReader::{get_ref, get_mut, into_inner}`
* `{Read,BufRead} for BufReader`
* `BufWriter`
* `BufWriter::{new, with_capacity}`
* `BufWriter::{get_ref, get_mut, into_inner}`
* `Write for BufWriter`
* `IntoInnerError`
* `IntoInnerError::{error, into_inner}`
* `{Error,Display} for IntoInnerError`
* `LineWriter`
* `LineWriter::{new, with_capacity}` - `with_capacity` was added
* `LineWriter::{get_ref, get_mut, into_inner}` - `get_mut` was added)
* `Write for LineWriter`
* `BufStream`
* `BufStream::{new, with_capacities}`
* `BufStream::{get_ref, get_mut, into_inner}`
* `{BufRead,Read,Write} for BufStream`
* `stdin`
* `Stdin`
* `Stdin::lock`
* `Stdin::read_line` - added method
* `StdinLock`
* `Read for Stdin`
* `{Read,BufRead} for StdinLock`
* `stdout`
* `Stdout`
* `Stdout::lock`
* `StdoutLock`
* `Write for Stdout`
* `Write for StdoutLock`
* `stderr`
* `Stderr`
* `Stderr::lock`
* `StderrLock`
* `Write for Stderr`
* `Write for StderrLock`
* `io::Result`
* `io::Error`
* `io::Error::last_os_error`
* `{Display, Error} for Error`
Unstable APIs:
(reasons can be found in the commit itself)
* `Write::flush`
* `Seek`
* `ErrorKind`
* `Error::new`
* `Error::from_os_error`
* `Error::kind`
Deprecated APIs
* `Error::description` - available via the `Error` trait
* `Error::detail` - available via the `Display` implementation
* `thread::Builder::{stdout, stderr}`
Changes in functionality:
* `old_io::stdio::set_stderr` is now a noop as the infrastructure for printing
backtraces has migrated to `std::io`.
* The `ReadExt`, `WriteExt`, and `BufReadExt` extension traits were all removed
by folding functionality into the corresponding trait.
[breaking-change]
When this attribute is applied to a function, its return value gets the
noalias attribute, which is how you tell LLVM that the function returns
a "new" pointer that doesn't alias anything accessible to the caller,
i.e. it acts like a memory allocator.
Plain malloc doesn't need this attribute because LLVM already knows
about malloc and adds the attribute itself.
This commit stabilizes essentially all of the new `std::path` API. The
API itself is changed in a couple of ways (which brings it in closer
alignment with the RFC):
* `.` components are now normalized away, unless they appear at the
start of a path. This in turn effects the semantics of e.g. asking for
the file name of `foo/` or `foo/.`, both of which yield `Some("foo")`
now. This semantics is what the original RFC specified, and is also
desirable given early experience rolling out the new API.
* The `parent` method is now `without_file` and succeeds if, and only
if, `file_name` is `Some(_)`. That means, in particular, that it fails
for a path like `foo/../`. This change affects `pop` as well.
In addition, the `old_path` module is now deprecated.
[breaking-change]
r? @alexcrichton
This commit stabilizes essentially all of the new `std::path` API. The
API itself is changed in a couple of ways (which brings it in closer
alignment with the RFC):
* `.` components are now normalized away, unless they appear at the
start of a path. This in turn effects the semantics of e.g. asking for
the file name of `foo/` or `foo/.`, both of which yield `Some("foo")`
now. This semantics is what the original RFC specified, and is also
desirable given early experience rolling out the new API.
* The `parent` function now succeeds if, and only if, the path has at
least one non-root/prefix component. This change affects `pop` as
well.
* The `Prefix` component now involves a separate `PrefixComponent`
struct, to better allow for keeping both parsed and unparsed prefix data.
In addition, the `old_path` module is now deprecated.
Closes#23264
[breaking-change]
The end result is that common fields (id, name, attributes, etc.) are stored in now-structures `ImplItem` and `TraitItem`.
The signature of a method is no longer duplicated between methods with a body (default/impl) and those without, they now share `MethodSig`.
This is also a [breaking-change] because of minor bugfixes and changes to syntax extensions:
* `pub fn` methods in a trait no longer parse - remove the `pub`, it has no meaning anymore
* `MacResult::make_methods` is now `make_impl_items` and the return type has changed accordingly
* `quote_method` is gone, because `P<ast::Method>` doesn't exist and it couldn't represent a full method anyways - could be replaced by `quote_impl_item`/`quote_trait_item` in the future, but I do hope we realize how silly that combinatorial macro expansion is and settle on a single `quote` macro + some type hints - or just no types at all (only token-trees)
r? @nikomatsakis This is necessary (hopefully also sufficient) for associated constants.
I've made some minor changes from the implementation attached to the RFC to try to minimize codegen. The methods now take `&Debug` trait objects rather than being parameterized and there are inlined stub methods that call to non-inlined methods to do the work.
r? @alexcrichton
cc @huonw for the `derive(Debug)` changes.
* Consumers of handle_options assume the unstable options are defined in
the getopts::Matches value if -Z unstable-options is set, but that's not
the case if there weren't any actual unstable options. Fix this by
always reparsing options when -Z unstable-options is set.
* If both argument parsing attempts fail, print the error from the second
attempt rather than the first. The error from the first is very poor
whenever unstable options are present. e.g.:
$ rustc hello.rs -Z unstable-options --show-span
error: Unrecognized option: 'show-span'.
$ rustc hello.rs -Z unstable-options --pretty --pretty
error: Unrecognized option: 'pretty'.
$ rustc hello.rs -Z unstable-options --pretty --bad-option
error: Unrecognized option: 'pretty'.
* On the second parse, add a separate pass to reject unstable options if
-Z unstable-options wasn't specified.
Fixes#21715.
r? @pnkfelix
These new APIs have had some time to bake now, and no pressing issues have come
up so they should be ok for stabilizing. Specifically, these two APIs were
stabilized:
* `slice::from_raw_parts`
* `slice::from_raw_parts_mut`
it turns out that jemalloc doesn't behave well on bitrig. with jemalloc enabled i get some kernel errors related to sbrk failures. with jemalloc disabled, the errors go away. i am investigating, but in the mean time, we should just disable jemalloc by default on bitrig.
Deleted trailing space in hello-cargo.md
Added note about build --release in hello-cargo
thanks to steven klabnik for pointing it out for me
edited out redundant wording
* Consumers of handle_options assume the unstable options are defined in
the getopts::Matches value if -Z unstable-options is set, but that's not
the case if there weren't any actual unstable options. Fix this by
always reparsing options when -Z unstable-options is set.
* If both argument parsing attempts fail, print the error from the second
attempt rather than the first. The error from the first is very poor
whenever unstable options are present. e.g.:
$ rustc hello.rs -Z unstable-options --show-span
error: Unrecognized option: 'show-span'.
$ rustc hello.rs -Z unstable-options --pretty --pretty
error: Unrecognized option: 'pretty'.
$ rustc hello.rs -Z unstable-options --pretty --bad-option
error: Unrecognized option: 'pretty'.
* On the second parse, add a separate pass to reject unstable options if
-Z unstable-options wasn't specified.
Fixes#21715.
r? @pnkfelix
Display::fmt for str calls into Formatter::pad, which is modest in size
and also pulls in string-related functions for its truncation and padding
abilities. For size-critical programs (e.g. embedded), this call site
may be the only reason Formatter::pad is linked into the output.
This commit performs another pass over the `std::char` module for stabilization.
Some minor cleanup is performed such as migrating documentation from libcore to
libunicode (where the `std`-facing trait resides) as well as a slight
reorganiation in libunicode itself. Otherwise, the stability modifications made
are:
* `char::from_digit` is now stable
* `CharExt::is_digit` is now stable
* `CharExt::to_digit` is now stable
* `CharExt::to_{lower,upper}case` are now stable after being modified to return
an iterator over characters. While the implementation today has not changed
this should allow us to implement the full set of case conversions in unicode
where some characters can map to multiple when doing an upper or lower case
mapping.
* `StrExt::to_{lower,upper}case` was added as unstable for a convenience of not
having to worry about characters expanding to more characters when you just
want the whole string to get into upper or lower case.
This is a breaking change due to the change in the signatures of the
`CharExt::to_{upper,lower}case` methods. Code can be updated to use functions
like `flat_map` or `collect` to handle the difference.
[breaking-change]
Closes#20333
This commit performs another pass over the `std::char` module for stabilization.
Some minor cleanup is performed such as migrating documentation from libcore to
libunicode (where the `std`-facing trait resides) as well as a slight
reorganiation in libunicode itself. Otherwise, the stability modifications made
are:
* `char::from_digit` is now stable
* `CharExt::is_digit` is now stable
* `CharExt::to_digit` is now stable
* `CharExt::to_{lower,upper}case` are now stable after being modified to return
an iterator over characters. While the implementation today has not changed
this should allow us to implement the full set of case conversions in unicode
where some characters can map to multiple when doing an upper or lower case
mapping.
* `StrExt::to_{lower,upper}case` was added as unstable for a convenience of not
having to worry about characters expanding to more characters when you just
want the whole string to get into upper or lower case.
This is a breaking change due to the change in the signatures of the
`CharExt::to_{upper,lower}case` methods. Code can be updated to use functions
like `flat_map` or `collect` to handle the difference.
[breaking-change]
These new APIs have had some time to bake now, and no pressing issues have come
up so they should be ok for stabilizing. Specifically, these two APIs were
stabilized:
* `slice::from_raw_parts`
* `slice::from_raw_parts_mut`
Add tests checking that a number of feature gates are gating their features
Namely:
* `quote`
* `link_args`
* `link_llvm_intrinsics`
* `thread_local`
* `unsafe_destructor`
Also updates test for `plugin_registrar` to make it clear that
it is only testing the `plugin_registrar` feature gate.
Cc #22820. (Latter is not fixed, since there are still a bunch more feature-gates that need tests. But I wanted to stop here and move on to something else.)
There was a buildbot failure recently of an arithmetic overflow in the isaac
module of the rand crate, so I've imported the isaac implementation from
out-of-tree which makes somewhat more liberal usage of the wrapping primitives.
Hopefull this quelches any future overflow!
Switching from generic bounds to trait objects and having un-inlined
inner methods should cut down on the size of Debug impls, since we care
about the speed of a Debug implementation way less than binary bloat.
There was a buildbot failure recently of an arithmetic overflow in the isaac
module of the rand crate, so I've imported the isaac implementation from
out-of-tree which makes somewhat more liberal usage of the wrapping primitives.
Hopefull this quelches any future overflow!
This may not be quite ready to go out, I fixed some docs but suspect I missed a bunch.
I also wound up fixing a bunch of redundant `[]` suffixes, but on closer inspection I don't believe that can land until after a snapshot.
Namely:
* `quote`
* `link_args`
* `link_llvm_intrinsics`
* `thread_local`
* `unsafe_destructor`
Also updates test for `plugin_registrar` to make it clear that
it is only testing the `plugin_registrar` feature gate.
Cc #22820.
Motivated by the test output not lining up when it could, I normalized all of the issue-* tests.
While doing it, I found some lexer tests that could be unignored and fixed an int -> isize.
If we end the `scoped` call with a semicolon, the `JoinGuard` will be
dropped and not returned from the `map`. The thread will start up and
we immediately block, making for a very expensive sequential loop.
rustc will ICE if you specify an outfile path that is bare without a
directory. As a workaround, before this -o ./foo will work
It wasn't clear to me where I could put a test that actually invokes rustc from a shell, although I think I can add doctests to that machinery in librustc_driver that will arrange for this to be called with arguments that would trigger the ICE
Motivated by the test output not lining up when it could, I normalized all of the issue-* tests.
While doing it, I found some lexer tests that could be unignored and fixed an int -> isize.
If we end the `scoped` call with a semicolon, the `JoinGuard` will be
dropped and not returned from the `map`. The thread will start up and
we immediately block, making for a very expensive sequential loop.
The docs currently define `array_expr`s as:
array_expr : '[' \"mut\" ? vec_elems? ']' ;
array_elems : [expr [',' expr]*] | [expr ',' \"..\" expr] ;
`vec_elems` is not defined anywhere else so it is probably a typo for `array_elems`.
Building on #22076, I've added some tests for stable methods in f32 and f64 that didn't have any before.
Please let me know if there are any improvements I can make, and I am happy to make them! 📬
Building on #22076, I've added some tests for stable methods in f32 and f64 that didn't have any before.
Please let me know if there are any improvements I can make, and I am happy to make them! 📬
* "let mut text" was previously of &String type. Now it is of &str type.
* Update the slicing syntax. Both &text[] and text.slice_from() evaluate
to a &str.
* We were passing a u32 to expr_usize. Call expr_u32 instead.
r? @steveklabnik
Fixes#23166
Right now the rust upgrade in cargo is blocked on fixing this overflow. If a
this benchmark is run it will trigger an overflow error today:
#[bench]
fn foo(b: &mut test::Bencher) {}
This commit adds a check on each iteration of the loop that the maximum
multiplier (10) doesn't overflow, and if it does just return the results so far.
* "let met text" was previously of &String type. Now it is of &str type.
* Update the slicing syntax. Both &text[] and text.slice_from() evaluate
to a &str.
* We were passing a u32 to expr_usize. Call expr_u32 instead.
This is a hack, but I don't think we can do much better as long as `derive` is running at the syntax expansion phase.
If the `custom_derive` feature gate is enabled, this works with user-defined traits and syntax extensions. Without the gate, you can't use e.g. `#[derive_Clone]` directly, so this does not change the stable language.
To make this effective, we now check gated attributes both before and after macro expansion. This uncovered a number of tests that were missing feature gates.
This PR also cleans up the deriving code somewhat, and forbids some previously-meaningless attribute syntax. For this reason it's technically a
[breaking-change]
r? @sfackler
We require the *deferred* loading, not just an opportunistic
asynchronous loading. I think `<script defer>` is safe to use,
according to <http://caniuse.com/#feat=script-defer>.
This is a hack, but I don't think we can do much better as long as `derive` is
running at the syntax expansion phase.
If the custom_derive feature gate is enabled, this works with user-defined
traits and syntax extensions. Without the gate, you can't use e.g. #[derive_Clone]
directly, so this does not change the stable language.
This commit also cleans up the deriving code somewhat, and forbids some
previously-meaningless attribute syntax. For this reason it's technically a
[breaking-change]
Being a person who somehow has taken a liking to premature optimisation, my knee-jerk reaction to
locking in std handles was preamble resembling following snippet:
let stdout = stdout();
let lstdout = stdout.lock();
let stdin = stdin();
let lstdin = stdin.lock();
and then reading from the locked handle like this:
let mut letter = [0; 1];
lstdin.read(&mut letter).unwrap();
As it is now this code will deadlock because the `read` method attempts to lock stdout as well!
r? @alexcrichton
---
Either way, I find flushing stdout when stdin is used debatable. I believe people who write prompts should take care to flush stdout when necessary themselves.
Another idea: Would be cool if locks on std handles would be taken for a thread, rather than a handle, so given preamble (first code snippet)
stdin.lock()
or more generally
stdin.read(…)
worked fine. I.e. if more than a single lock are all taken inside the same thread, it would work, though not sure if our synchronisation primitives are expressive enough to make it possible.
The `std::net` primitives should be ready for use now and as a result the old
ones are now deprecated and slated for removal. Most TCP/UDP functionality is
now available through `std::net` but the `std::old_io::net::pipe` module is
removed entirely from the standard library.
Unix socket funtionality can be found in sfackler's [`unix_socket`][unix] crate
and there is currently no replacement for named pipes on Windows.
[unix]: https://crates.io/crates/unix_socket
[breaking-change]
since there are separate checks that apply to Copy (and Send uses the
generic defaulted trait rules). Also prohibit `Sized` from being
manually implemented for now.
now have a simple set of trait def-ids. During coherence, we use a
separate table to track the default impls for any given trait so that we
can report a nice error. This fixes various bugs in the metadata
encoding that led to `ty::trait_has_default_impl` yielding the wrong
values in the cross-crate case. (In particular, default impl def-ids
were not included in the list of all impl def-ids; I debated fixing just
that, but this approach seemed cleaner overall, since we usually treat
the "defaulted" bit on traits as being a property of the trait, and now
iterating over a list of impls doesn't intermingle default impls with
normal impls.)
Right now the rust upgrade in cargo is blocked on fixing this overflow. If a
this benchmark is run it will trigger an overflow error today:
#[bench]
fn foo(b: &mut test::Bencher) {}
This commit adds a check on each iteration of the loop that the maximum
multiplier (10) doesn't overflow, and if it does just return the results so far.
The `std::net` primitives should be ready for use now and as a result the old
ones are now deprecated and slated for removal. Most TCP/UDP functionality is
now available through `std::net` but the `std::old_io::net::pipe` module is
removed entirely from the standard library.
Unix socket funtionality can be found in sfackler's [`unix_socket`][unix] crate
and there is currently no replacement for named pipes on Windows.
[unix]: https://crates.io/crates/unix_socket
[breaking-change]
This should fix#22615. Previously, the playpen links grabbed the content of all `.rusttest` containers on the same level to build the URL. Now they just select the one before the `pre` they are shown in.
I have only tested this by changing the file in my local build of the docs (not by running rustdoc itself).
This concretely improves type inference of some cases (see included
test). I assume the compiler struggles to reason about multiple layers
of generic type parameters (even with associated-type equalities) but
*can* understand pure associated types, since they are always directly
computable from the input types.
Thanks to @shepmaster for noticing the issue with `Cloned` (I took that example as a test case).
Being a person who somehow has taken a liking to premature optimisation, my knee-jerk reaction to
locking in std handles was preamble resembling following snippet:
let stdout = stdout();
let lstdout = stdout.lock();
let stdin = stdin();
let lstdin = stdin.lock();
and then reading from the locked handle like this:
let mut letter = [0; 1];
lstdin.read(&mut letter).unwrap();
As it is now this code will deadlock because the `read` method attempts to lock stdout as well!
