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.
Changes:
* default value when no args
* license
* removed libc printing
* use extra::bigint instead of handmade gmp binding
The drawback is that it's 2 order of magnitude slower, the good news is that there is a good bench for extra::bigint.
If a function is marked as external, then it's likely desired for use with some
native library, so we're not really accomplishing a whole lot by internalizing
all of these symbols.
If a function is marked as external, then it's likely desired for use with some
native library, so we're not really accomplishing a whole lot by internalizing
all of these symbols.
* moved `extern` inside module
* changed `extern "stdcall"` to `extern "system"`
* changed `cfg(target_os="win32")` to `cfg(windows)`
* only run on Windows && x86, (not x86_64)
* updated copyright dates
There was a syntax error because the `extern "stdcall"` was outside the module instead of inside it.
* moved `extern` inside module
* change `extern "stdcall"` to `extern "system"`
* change `cfg(target_os="win32")` to `cfg(windows)`
* updated copyright dates
* changed log(error, ...) => info!(....)
* added `pub` keyword to kernel32 functions
Changes:
* add licence;
* remove usage of libc and unsafe;
* use BufferedWriter to improve performance;
* use a DummyWriter to cancel binary output in test.
Changes:
* add licence;
* remove usage of libc and unsafe;
* use BufferedWriter to improve performance;
* use a DummyWriter to cancel binary output in test.
This implementation of the meteor contest implements:
- insertion check with bit trick;
- pregenetation of every feasible placement of the pieces on the
board;
- filtering of placement that implies unfeasible board
- central symetry breaking
related to #2776
I've started working on this issue and pushed a small commit, which adds a range check for integer literals in `middle::const_eval` (no `uint` at the moment)
At the moment, this patch is just a proof of concept, I'm not sure if there is a better function for the checks in `middle::const_eval`. This patch does not check for overflows after constant folding, eg:
let x: i8 = 99 + 99;
Bare functions are another example of a scalar but non-numeric
type (like char) that should be handled separately in casts.
This disallows expressions like `0 as extern "Rust" fn() -> int;`.
It might be advantageous to allow casts between bare functions
and raw pointers in unsafe code in the future, to pass function
pointers between Rust and C.
Closes#8728
This implementation of the meteor contest implements:
- insertion check with bit trick;
- pregenetation of every feasible placement of the pieces on the
board;
- filtering of placement that implies unfeasible board
- central symetry breaking
Rename {struct-update,fsu}-moves-and-copies, since win32
failed to run the test since UAC prevents any executable whose
name contaning "update". (#10452)
Some tests related to #9205 are expected to fail on gcc 4.8,
so they are marked as `xfail-win32` instead of `xfail-fast`.
Some tests using `extra::tempfile` fail on win32 due to #10462.
Mark them as `xfail-win32`.
This commit re-organizes the io::native module slightly in order to have a
working implementation of rtio::IoFactory which uses native implementations. The
goal is to seamlessly multiplex among libuv/native implementations wherever
necessary.
Right now most of the native I/O is unimplemented, but we have existing bindings
for file descriptors and processes which have been hooked up. What this means is
that you can now invoke println!() from libstd with no local task, no local
scheduler, and even without libuv.
There's still plenty of work to do on the native I/O factory, but this is the
first steps into making it an official portion of the standard library. I don't
expect anyone to reach into io::native directly, but rather only std::io
primitives will be used. Each std::io interface seamlessly falls back onto the
native I/O implementation if the local scheduler doesn't have a libuv one
(hurray trait ojects!)
This commit re-organizes the io::native module slightly in order to have a
working implementation of rtio::IoFactory which uses native implementations. The
goal is to seamlessly multiplex among libuv/native implementations wherever
necessary.
Right now most of the native I/O is unimplemented, but we have existing bindings
for file descriptors and processes which have been hooked up. What this means is
that you can now invoke println!() from libstd with no local task, no local
scheduler, and even without libuv.
There's still plenty of work to do on the native I/O factory, but this is the
first steps into making it an official portion of the standard library. I don't
expect anyone to reach into io::native directly, but rather only std::io
primitives will be used. Each std::io interface seamlessly falls back onto the
native I/O implementation if the local scheduler doesn't have a libuv one
(hurray trait ojects!)
