Closes#14184 (std: Move the owned module from core to std)
Closes#14183 (Allow blocks in const expressions)
Closes#14176 (Add tests for from_bits.)
Closes#14175 (Replaced ~T by Box<T> in manual)
Closes#14173 (Implements Default trait for BigInt and BigUint)
Closes#14171 (Fix#8391)
Closes#14159 (Clean up unicode code in libstd)
Closes#14126 (docs: Add a not found page)
Closes#14123 (add a line to the example to clarify semantics)
Closes#14106 (Pretty printer improvements)
Closes#14083 (rustllvm: Add LLVMRustArrayType)
Closes#13957 (io: Implement process wait timeouts)
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.
When printing doc comments, always put a newline after them in a macro
invocation to ensure that a line-doc-comment doesn't consume remaining tokens on
the line.
Now that the #[deriving] attribute is removed, the raw_pointers_deriving lint
was broken. This commit restores the lint by preserving lint attributes
across #[deriving] to the implementations and using #[automatically_derived] as
the trigger for activating the lint.
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`.
Some `Expr` needs parentheses when printed. For example, without
parentheses, `ExprUnary(UnNeg, ExprBinary(BiAdd, ..))` becomes
`-lhs + rhs` which is wrong.
Those cases don't appear in ordinary code (since parentheses are
explicitly added) but they can appear in manually crafted ast by
extensions.
Inject `extern crate {std, native}` before `use` statements.
Add `#![feature(glob)]` since `use std::prelude::*` is used.
(Unfortunately `rustc --pretty expanded` does not converge,
since `extern crate` and `use std::prelude::*` is injected at every
iteration.)
This is to clarify that match construct doesn't define a new variable, since I
observed a person reading the Rust tutorial who seemed to incorrectly think
that it did. Fixes https://github.com/mozilla/rust/issues/13571 .
The Normalizations iterator has been renamed to Decompositions.
It does not currently include all forms of Unicode normalization,
but only encompasses decompositions.
If implemented recomposition would likely be a separate iterator
which works on the result of this one.
[breaking-change]
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]
On 32bit platforms, int is the same as i32, so 0xffffffff is "out of
range." Annotating variables as u32 fixes the problems.
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
- Use Unicode-aware versions of `CreateProcess` (Fixes#13815) and `Get/FreeEnvironmentStrings`.
- Includes a helper function `os::win32::as_mut_utf16_p`, which does the same thing as `os::win32::as_utf16_p` except the pointer is mutable.
- Fixed `make_command_line` to handle Unicode correctly.
- Tests for the above.
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.
Previously, make_command_line iterates over each u8 in the string and
then appends them as chars, so any non-ASCII string will get horribly
mangled by this function. This fix should allow Unicode arguments to
work correctly in native::io::process::spawn.
Changed libnative to use CreateProcessW instead of CreateProcessA. In
addition, the lpEnvironment parameter now uses Unicode.
Added a helper function os::win32::as_mut_utf16_p, which does basically
the same thing as os::win32::as_utf16_p except the pointer is mutable.
Changed StrBuf.shift_byte() that it no longer reallocates the buffer by just calling Vec.shift();
Added warning to shift_char()'s docs about it having to copy the whole buffer, as per the docs for
Vec.shift().
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.
