In order to have the spawning semantics be the same for unix/windows, the
child's PATH environment variable needs to be searched rather than the parent's
environment variable.
If the child is inheriting the parent's PATH, then no action need be taken as
windows will do the heavy lifting. If the child specifies its own PATH, then it
is searched beforehand for the target program and the result is favored if a hit
is found.
cc #15149, but does not close the issue because libgreen still needs to be
updated.
This commit changes the `io::process::Command` API to provide
fine-grained control over the environment:
* The `env` method now inserts/updates a key/value pair.
* The `env_remove` method removes a key from the environment.
* The old `env` method, which sets the entire environment in one shot,
is renamed to `env_set_all`. It can be used in conjunction with the
finer-grained methods. This renaming is a breaking change.
To support these new methods, the internal `env` representation for
`Command` has been changed to an optional `HashMap` holding owned
`CString`s (to support non-utf8 data). The `HashMap` is only
materialized if the environment is updated. The implementation does not
try hard to avoid allocation, since the cost of launching a process will
dwarf any allocation cost.
This patch also adds `PartialOrd`, `Eq`, and `Hash` implementations for
`CString`.
[breaking-change]
This implementation does have the minor issue of not handling things correctly when a codepoint is split across multiple writes or reads, but its better than not having unicode support at all.
Adds a Windows specific struct `WindowsTTY` in `libnative` and make `tty_open` create that struct on Windows. Adds needed functions and constants to `c_win32.rs`.
Libuv still needs to be updated before #15028 can be closed.
It was required to get iOS compilable but since
that time a couple of changes were introduced
which cause the same bug to re-appear and broke
build anyway. Fixing all of them doesn’t look a
viable alternative to me as it will pollute the
code too much.
So it should be fixed from LLVM side and I hope
LLVM will upstream corresponding changes in a
month.
Meanwhile, who wants to play with Rust on iOS is
better to use a fork which uses patched LLVM:
https://github.com/vhbit/rust/tree/ios . It may
lag behind master a bit, but it is Travis-checked
to compile successfully.
It was required to get iOS compilable but since
that time a couple of changes were introduced
which cause the same bug to re-appear and broke
build anyway. Fixing all of them doesn’t look a
viable alternative to me as it will pollute the
code too much.
So it should be fixed from LLVM side and I hope
LLVM will upstream corresponding changes in a
month.
Meanwhile, who wants to play with Rust on iOS is
better to use a fork which uses patched LLVM:
https://github.com/vhbit/rust/tree/ios . It may
lag behind master a bit, but it is Travis-checked
to compile successfully.
POSIX has recvfrom(2) and sendto(2), but their name seem not to be
suitable with Rust. We already renamed getpeername(2) and
getsockname(2), so I think it makes sense.
Alternatively, `receive_from` would be fine. However, we have `.recv()`
so I chose `recv_from`.
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
Closes#14358.
~~The tests are not yet moved to `utf16_iter`, so this probably won't compile. I'm submitting this PR anyway so it can be reviewed and since it was mentioned in #14611.~~ EDIT: Tests now use `utf16_iter`.
This deprecates `.to_utf16`. `x.to_utf16()` should be replaced by either `x.utf16_iter().collect::<Vec<u16>>()` (the type annotation may be optional), or just `x.utf16_iter()` directly, if it can be used in an iterator context.
[breaking-change]
cc @huonw
This deprecates `.to_utf16`. `x.to_utf16()` should be replaced by either
`x.utf16_units().collect::<Vec<u16>>()` (the type annotation may be optional), or
just `x.utf16_units()` directly, if it can be used in an iterator context.
Closes#14358
[breaking-change]
floating point numbers for real.
This will break code that looks like:
let mut x = 0;
while ... {
x += 1;
}
println!("{}", x);
Change that code to:
let mut x = 0i;
while ... {
x += 1;
}
println!("{}", x);
Closes#15201.
[breaking-change]
This change registers new snapshots, allowing `*T` to be removed from the language. This is a large breaking change, and it is recommended that if compiler errors are seen that any FFI calls are audited to determine whether they should be actually taking `*mut T`.
Since procs do not have lifetime bounds, we must do this to maintain
safety.
This can break code that incorrectly captured references in procedure
types. Change such code to not do this, perhaps with a trait object
instead.
A better solution would be to add higher-rank lifetime support to procs.
However, this would be a lot of work for a feature we want to remove in
favor of unboxed closures. The corresponding "real fix" is #15067.
Closes#14036.
[breaking-change]
Most of the comments are available on the Task structure itself, but this commit
is aimed at making FFI-style usage of Rust tasks a little nicer.
Primarily, this commit enables re-use of tasks across multiple invocations. The
method `run` will no longer unconditionally destroy the task itself. Rather, the
task will be internally re-usable if the closure specified did not fail. Once a
task has failed once it is considered poisoned and it can never be used again.
Along the way I tried to document shortcomings of the current method of tearing
down a task, opening a few issues as well. For now none of the behavior is a
showstopper, but it's useful to acknowledge it. Also along the way I attempted
to remove as much `unsafe` code as possible, opting for safer abstractions.
This change starts denying `*T` in the parser. All code using `*T` should ensure
that the FFI call does indeed take `const T*` on the other side before renaming
the type to `*const T`.
Otherwise, all code can rename `*T` to `*const T`.
[breaking-change]
This breaks a fair amount of code. The typical patterns are:
* `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`;
* `println!("{}", 3)`: change to `println!("{}", 3i)`;
* `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`.
RFC #30. Closes#6023.
[breaking-change]
The aim of these changes is not working out a generic bi-endianness architectures support but to allow people develop for little endian MIPS machines (issue #7190).
If you define lang items in your crate, add `#[feature(lang_items)]`.
If you define intrinsics (`extern "rust-intrinsic"`), add
`#[feature(intrinsics)]`.
Closes#12858.
[breaking-change]
Closes#8142.
This is not the semantics we want long-term. You can continue to use
`#[unsafe_destructor]`, but you'll need to add
`#![feature(unsafe_destructor)]` to the crate attributes.
[breaking-change]
This creates a stability baseline for all crates that we distribute that are not `std`. In general, all library code must start as experimental and progress in stages to become stable.
Replace its usage with byte string literals, except in `bytes!()` tests.
Also add a new snapshot, to be able to use the new b"foo" syntax.
The src/etc/2014-06-rewrite-bytes-macros.py script automatically
rewrites `bytes!()` invocations into byte string literals.
Pass it filenames as arguments to generate a diff that you can inspect,
or `--apply` followed by filenames to apply the changes in place.
Diffs can be piped into `tip` or `pygmentize -l diff` for coloring.
This patch consolidates and cleans up the task spawning APIs:
* Removes the problematic `future_result` method from `std::task::TaskBuilder`,
and adds a `try_future` that both spawns the task and returns a future
representing its eventual result (or failure).
* Removes the public `opts` field from `TaskBuilder`, instead adding appropriate
builder methods to configure the task.
* Adds extension traits to libgreen and libnative that add methods to
`TaskBuilder` for spawning the task as a green or native thread.
Previously, there was no way to benefit from the `TaskBuilder` functionality and
also set the scheduler to spawn within.
With this change, all task spawning scenarios are supported through the
`TaskBuilder` interface.
Closes#3725.
[breaking-change]
* os::pipe() now returns IoResult<os::Pipe>
* os::pipe() is now unsafe because it does not arrange for deallocation of file
descriptors
* os::Pipe fields are renamed from input to reader and out to write.
* PipeStream::pair() has been added. This is a safe method to get a pair of
pipes.
* Dealing with pipes in native process bindings have been improved to be more
robust in the face of failure and intermittent errors. This converts a few
fail!() situations to Err situations.
Closes#9458
cc #13538Closes#14724
[breaking-change]
Closes#14797 (librustc: Fix the issue with labels shadowing variable names by making)
Closes#14823 (Improve error messages for io::fs)
Closes#14827 (libsyntax: Allow `+` to separate trait bounds from objects.)
Closes#14834 (configure: Don't sync unused submodules)
Closes#14838 (Remove typo on collections::treemap::UnionItems)
Closes#14839 (Fix the unused struct field lint for struct variants)
Closes#14840 (Clarify `Any` docs)
Closes#14846 (rustc: [T, ..N] and [T, ..N+1] are not the same)
Closes#14847 (Audit usage of NativeMutex)
Closes#14850 (remove unnecessary PaX detection)
Closes#14856 (librustc: Take in account mutability when casting array to raw ptr.)
Closes#14859 (librustc: Forbid `transmute` from being called on types whose size is)
Closes#14860 (Fix `quote_pat!` & parse outer attributes in `quote_item!`)
This uncovered some dead code, most notably in middle/liveness.rs, which I think suggests there must be something fishy with that part of the code.
The #[allow(dead_code)] annotations on some of the fields I am not super happy about but as I understand, marker type may disappear at some point.
This refers to green, which (AFAICT) has everything implemented. In
particular, this will help guide people to get working signal handling
via libgreen.
