This commit fills in the documentation holes for the FormatWriter trait which
were previously accidentally left blank. Additionally, this adds the `write_fmt`
method to the trait to allow usage of the `write!` macro with implementors of
the `FormatWriter` trait. This is not useful for consumers of the standard
library who should generally avoid the `FormatWriter` trait, but it is useful
for consumers of the core library who are not using the standard library.
This slightly adjusts the NullablePointer representation for some enums in the case where the non-nullable variant has a single field (the ptr field) to be just that, the pointer. This is in contrast to the current behaviour where we'd wrap that single pointer in a LLVM struct.
Fixes#11040 & #11303.
This commit fills in the documentation holes for the FormatWriter trait which
were previously accidentally left blank. Additionally, this adds the `write_fmt`
method to the trait to allow usage of the `write!` macro with implementors of
the `FormatWriter` trait. This is not useful for consumers of the standard
library who should generally avoid the `FormatWriter` trait, but it is useful
for consumers of the core library who are not using the standard library.
This commit is part of the libstd facade RFC, issue #13851. This creates a new
library, liballoc, which is intended to be the core allocation library for all
of Rust. It is pinned on the basic assumption that an allocation failure is an
abort or failure.
This module has inherited the heap/libc_heap modules from std::rt, the owned/rc
modules from std, and the arc module from libsync. These three pointers are
currently the three most core pointer implementations in Rust.
The UnsafeArc type in std::sync should be considered deprecated and replaced by
Arc<Unsafe<T>>. This commit does not currently migrate to this type, but future
commits will continue this refactoring.
This plugs a leak where resolve was treating enums defined in parent modules as
in-scope for all children modules when resolving a pattern identifier. This
eliminates the code path in resolve entirely.
If this breaks any existing code, then it indicates that the variants need to be
explicitly imported into the module.
Closes#14221
This is an implementation of RFC 16. A module can now only be loaded if the
module declaring `mod name;` "owns" the current directory. A module is
considered as owning its directory if it meets one of the following criteria:
* It is the top-level crate file
* It is a `mod.rs` file
* It was loaded via `#[path]`
* It was loaded via `include!`
* The module was declared via an inline `mod foo { ... }` statement
For example, this directory structure is now invalid
// lib.rs
mod foo;
// foo.rs
mod bar;
// bar.rs;
fn bar() {}
With this change `foo.rs` must be renamed to `foo/mod.rs`, and `bar.rs` must be
renamed to `foo/bar.rs`. This makes it clear that `bar` is a submodule of `foo`,
and can only be accessed through `foo`.
RFC: 0016-module-file-system-hierarchy
Closes#14180
[breaking-change]
This plugs a leak where resolve was treating enums defined in parent modules as
in-scope for all children modules when resolving a pattern identifier. This
eliminates the code path in resolve entirely.
If this breaks any existing code, then it indicates that the variants need to be
explicitly imported into the module.
Closes#14221
[breaking-change]
1. Wherever the `buf` field of a `Formatter` was used, the `Formatter` is used
instead.
2. The usage of `write_fmt` is minimized as much as possible, the `write!` macro
is preferred wherever possible.
3. Usage of `fmt::write` is minimized, favoring the `write!` macro instead.
Each test works by rendering the flowgraph for the last identified
block we see in expanded pretty-printed output, and comparing it (via
`diff`) against a checked in "foo.dot-expected.dot" file.
Each test post-processes the output to remove NodeIds ` (id=NUM)` so
that the expected output is somewhat stable (or at least independent
of how we assign NodeIds) and easier for a human to interpret when
looking at the expected output file itself.
----
Test writing style notes:
I usually tried to write the tests in a way that would avoid duplicate
labels in the output rendered flow graph, when possible.
The tests that have string literals "unreachable" in the program text
are deliberately written that way to remind the reader that the
unreachable nodes in the resulting graph are not an error in the
control flow computation, but rather a natural consequence of its
construction.
After discussion with Alex, we think the proper policy is for dtors
to not fail. This is consistent with C++. BufferedWriter already
does this, so this patch modifies TempDir to not fail in the dtor,
adding a `close` method for handling errors on destruction.
## Process API
The existing APIs for spawning processes took strings for the command
and arguments, but the underlying system may not impose utf8 encoding,
so this is overly limiting.
The assumption we actually want to make is just that the command and
arguments are viewable as [u8] slices with no interior NULLs, i.e., as
CStrings. The ToCStr trait is a handy bound for types that meet this
requirement (such as &str and Path).
However, since the commands and arguments are often a mixture of
strings and paths, it would be inconvenient to take a slice with a
single T: ToCStr bound. So this patch revamps the process creation API
to instead use a builder-style interface, called `Command`, allowing
arguments to be added one at a time with differing ToCStr
implementations for each.
The initial cut of the builder API has some drawbacks that can be
addressed once issue #13851 (libstd as a facade) is closed. These are
detailed as FIXMEs.
## Dynamic library API
`std::unstable::dynamic_library::open_external` currently takes a
`Path`, but because `Paths` produce normalized strings, this can
change the semantics of lookups in a given environment. This patch
generalizes the function to take a `ToCStr`-bounded type, which
includes both `Path`s and `str`s.
## ToCStr API
Adds ToCStr impl for &Path and ~str. This is a stopgap until DST (#12938) lands.
Until DST lands, we cannot decompose &str into & and str, so we cannot
usefully take ToCStr arguments by reference (without forcing an
additional & around &str). So we are instead temporarily adding an
instance for &Path and ~str, so that we can take ToCStr as owned. When
DST lands, the &Path instance should be removed, the string instances
should be revisted, and arguments bound by ToCStr should be passed by
reference.
FIXMEs have been added accordingly.
## Tickets closed
Closes#11650.
Closes#7928.
(Only after adding the tests did I realize that this is not really a
special case at the AST level; as far as the visitor is concerned,
`int` and `i32` and `i64` are just idents.)
Namely: non-pub `use` declarations *are* significant to the SVH
computation, since they can change which traits are part of the method
resolution step, and thus affect which methods get called from the
(potentially inlined) code.
The existing APIs for spawning processes took strings for the command
and arguments, but the underlying system may not impose utf8 encoding,
so this is overly limiting.
The assumption we actually want to make is just that the command and
arguments are viewable as [u8] slices with no interior NULLs, i.e., as
CStrings. The ToCStr trait is a handy bound for types that meet this
requirement (such as &str and Path).
However, since the commands and arguments are often a mixture of
strings and paths, it would be inconvenient to take a slice with a
single T: ToCStr bound. So this patch revamps the process creation API
to instead use a builder-style interface, called `Command`, allowing
arguments to be added one at a time with differing ToCStr
implementations for each.
The initial cut of the builder API has some drawbacks that can be
addressed once issue #13851 (libstd as a facade) is closed. These are
detailed as FIXMEs.
Closes#11650.
[breaking-change]
Provides better help for the resolve failures inside an `impl` if the name matches:
- a field on the self type
- a method on the self type
- a method on the current trait ref (in a trait impl)
Not handling trait method suggestions if in a regular `impl` (as you can see on line 69 of the test), I believe it is possible though.
Also, provides a better message when `self` fails to resolve due to being a static method.
It's using some unsafe pointers to skip copying the larger structures (which are only used in error conditions); it's likely possible to get it working with lifetimes (all the useful refs should outlive the visitor calls) but I haven't really figured that out for this case. (can switch to copying code if wanted)
Closes#2356.
This implements set_timeout() for std::io::Process which will affect wait()
operations on the process. This follows the same pattern as the rest of the
timeouts emerging in std::io::net.
The implementation was super easy for everything except libnative on unix
(backwards from usual!), which required a good bit of signal handling. There's a
doc comment explaining the strategy in libnative. Internally, this also required
refactoring the "helper thread" implementation used by libnative to allow for an
extra helper thread (not just the timer).
This is a breaking change in terms of the io::Process API. It is now possible
for wait() to fail, and subsequently wait_with_output(). These two functions now
return IoResult<T> due to the fact that they can time out.
Additionally, the wait_with_output() function has moved from taking `&mut self`
to taking `self`. If a timeout occurs while waiting with output, the semantics
are undesirable in almost all cases if attempting to re-wait on the process.
Equivalent functionality can still be achieved by dealing with the output
handles manually.
[breaking-change]
cc #13523
LLVM internally uses `uint64_t` for array size, but the corresponding
C API (`LLVMArrayType`) uses `unsigned int` so ths value is truncated.
Therefore rustc generates wrong type for fixed-sized large vector e.g.
`[0 x i8]` for `[0u8, ..(1 << 32)]`.
This patch adds `LLVMRustArrayType` function for `uint64_t` support.
Integers are always parsed as a u64 in libsyntax, but they're stored as i64. The
parser and pretty printer both printed an i64 instead of u64, sometimes
introducing an extra negative sign.
* Added `// no-pretty-expanded` to pretty-print a test, but not run it through
the `expanded` variant.
* Removed #[deriving] and other expanded attributes after they are expanded
* Removed hacks around &str and &&str and friends (from both the parser and the
pretty printer).
* Un-ignored a bunch of tests
After testing `--pretty normal`, it tries to run `--pretty expanded` and
typecheck output.
Here we don't check convergence since it really diverges: for every
iteration, some extra lines (e.g.`extern crate std`) are inserted.
Some tests are `ignore-pretty`-ed since they cause various issues
with `--pretty expanded`.
The compiler was updated to recognize that implementations for ty_uniq(..) are
allowed if the Box lang item is located in the current crate. This enforces the
idea that libcore cannot allocated, and moves all related trait implementations
from libcore to libstd.
This is a breaking change in that the AnyOwnExt trait has moved from the any
module to the owned module. Any previous users of std::any::AnyOwnExt should now
use std::owned::AnyOwnExt instead. This was done because the trait is intended
for Box traits and only Box traits.
[breaking-change]
Added a run-pass test to ensure that processes can be correctly spawned
using non-ASCII arguments, working directory, and environment variables.
It also tests Unicode support of os::env_as_bytes.
An additional assertion was added to the test for make_command_line to
verify it handles Unicode correctly.
Been meaning to try my hand at something like this for a while, and noticed something similar mentioned as part of #13537. The suggestion on the original ticket is to use `TcpStream::open(&str)` to pass in a host + port string, but seems a little cleaner to pass in host and port separately -- so a signature like `TcpStream::open(&str, u16)`.
Also means we can use std::io::net::addrinfo directly instead of using e.g. liburl to parse the host+port pair from a string.
One outstanding issue in this PR that I'm not entirely sure how to address: in open_timeout, the timeout_ms will apply for every A record we find associated with a hostname -- probably not the intended behavior, but I didn't want to waste my time on elaborate alternatives until the general idea was a-OKed. :)
Anyway, perhaps there are other reasons for us to prefer the original proposed syntax, but thought I'd get some thoughts on this. Maybe there are some solid reasons to prefer using liburl to do this stuff.
Prior to this commit, TcpStream::connect and TcpListener::bind took a
single SocketAddr argument. This worked well enough, but the API felt a
little too "low level" for most simple use cases.
A great example is connecting to rust-lang.org on port 80. Rust users would
need to:
1. resolve the IP address of rust-lang.org using
io::net::addrinfo::get_host_addresses.
2. check for errors
3. if all went well, use the returned IP address and the port number
to construct a SocketAddr
4. pass this SocketAddr to TcpStream::connect.
I'm modifying the type signature of TcpStream::connect and
TcpListener::bind so that the API is a little easier to use.
TcpStream::connect now accepts two arguments: a string describing the
host/IP of the host we wish to connect to, and a u16 representing the
remote port number.
Similarly, TcpListener::bind has been modified to take two arguments:
a string describing the local interface address (e.g. "0.0.0.0" or
"127.0.0.1") and a u16 port number.
Here's how to port your Rust code to use the new TcpStream::connect API:
// old ::connect API
let addr = SocketAddr{ip: Ipv4Addr{127, 0, 0, 1}, port: 8080};
let stream = TcpStream::connect(addr).unwrap()
// new ::connect API (minimal change)
let addr = SocketAddr{ip: Ipv4Addr{127, 0, 0, 1}, port: 8080};
let stream = TcpStream::connect(addr.ip.to_str(), addr.port()).unwrap()
// new ::connect API (more compact)
let stream = TcpStream::connect("127.0.0.1", 8080).unwrap()
// new ::connect API (hostname)
let stream = TcpStream::connect("rust-lang.org", 80)
Similarly, for TcpListener::bind:
// old ::bind API
let addr = SocketAddr{ip: Ipv4Addr{0, 0, 0, 0}, port: 8080};
let mut acceptor = TcpListener::bind(addr).listen();
// new ::bind API (minimal change)
let addr = SocketAddr{ip: Ipv4Addr{0, 0, 0, 0}, port: 8080};
let mut acceptor = TcpListener::bind(addr.ip.to_str(), addr.port()).listen()
// new ::bind API (more compact)
let mut acceptor = TcpListener::bind("0.0.0.0", 8080).listen()
[breaking-change]
