This isn't very useful yet, but it does replace most functionality of `@T`. The `Mut<T>` type will make it unnecessary to have a `GcMut<T>` so I haven't included one. Obviously it doesn't work for trait objects but that needs to be figured out for `Rc<T>` too.
This was needed to access UEFI boot services in my new Boot2Rust experiment.
I also realized that Rust functions declared as extern always use the C calling convention regardless of how they were declared, so this pull request fixes that as well.
This implements a fair amount of the unimpl() functionality in io::native
relating to filesystem operations. I've also modified all io::fs tests to run in
both a native and uv environment (so everything is actually tested).
There are a few bits of remaining functionality which I was unable to get
working:
* truncate on windows
* change_file_times on windows
* lstat on windows
I think that change_file_times may just need a better interface, but the other
two have large implementations in libuv which I didn't want to tackle trying to
copy. I found a `chsize` function to work for truncate on windows, but it
doesn't quite seem to be working out.
This implements a fair amount of the unimpl() functionality in io::native
relating to filesystem operations. I've also modified all io::fs tests to run in
both a native and uv environment (so everything is actually tested).
There are a two bits of remaining functionality which I was unable to get
working:
* change_file_times on windows
* lstat on windows
I think that change_file_times may just need a better interface, but lstat has a
large implementation in libuv which I didn't want to tackle trying to copy.
There are issues with reading stdin when it is actually attached to a pipe, but
I have run into no problems in writing to stdout/stderr when they are attached
to pipes.
ToStr, Encodable and Decodable are not marked as such, since they're
already expensive, and lead to large methods, so inlining will bloat the
metadata & the binaries.
This means that something like
#[deriving(Eq)]
struct A { x: int }
creates an instance like
#[doc = "Automatically derived."]
impl ::std::cmp::Eq for A {
#[inline]
fn eq(&self, __arg_0: &A) -> ::bool {
match *__arg_0 {
A{x: ref __self_1_0} =>
match *self {
A{x: ref __self_0_0} => true && __self_0_0.eq(__self_1_0)
}
}
}
#[inline]
fn ne(&self, __arg_0: &A) -> ::bool {
match *__arg_0 {
A{x: ref __self_1_0} =>
match *self {
A{x: ref __self_0_0} => false || __self_0_0.ne(__self_1_0)
}
}
}
}
(The change being the `#[inline]` attributes.)
Provide `Closed01` and `Open01` that generate directly from the
closed/open intervals from 0 to 1, in contrast to the plain impls for
f32 and f64 which generate the half-open [0,1).
Fixes#7755.
This adds a new `std::unstable::mutex` module which contains bindings to the platform-provided mutexes. This module is pretty much entirely unsafe to use, but is critical for the runtime and dropping our C++ dependency.
The actual implementation is to do a compare-and-swap on an initially uninitialized pointer. Pthreads does allow for static initialization, so this wouldn't be necessary if we had all the proper headers and whatnot, but windows it looks like will always require some sort of compare-and-swap operation. For now, I didn't want to have to define all the pthreads headers, so I continue to just malloc the pthreads lock/cvar.
After this, there's only one remaining C++ component of rust, and that's unwinding.
Explicitly have the only C++ portion of the runtime be one file with exception
handling. All other runtime files must now live in C and be fully defined in C.
This mutex is built on top of pthreads for unix and the related windows apis on
windows. This is a straight port of the lock_and_signal type from C++ to rust.
Almost all operations on the type are unsafe, and it's definitely not
recommended for general use.
Closes#9105
This replaces `*` with `..` in enums, `_` with `..` in structs, and `.._` with `..` in vectors. It adds obsolete syntax warnings for the old forms but doesn't turn them on yet because we need a snapshot.
#5830
There are issues with reading stdin when it is actually attached to a pipe, but
I have run into no problems in writing to stdout/stderr when they are attached
to pipes.
