`FormatMessageW()` is called by `std::os::last_os_error()` to convert
errno into string, but the function may fail on non-english locale.
I don't know why it fails, but anyway it's better to return errno
than to `fail!()` in the case.
Fixes#13075Fixes#13073
`FormatMessageW()` is called by `std::os::last_os_error()` to convert
errno into string, but the function may fail on non-english locale.
I don't know why it fails, but anyway it's better to return errno
than to `fail!()` in the case.
Fixes#13075Fixes#13073
This is a very minor edit to the tutorial section on references.
Reading this section for the first time, I stumbled on the phrase "a reference can be borrowed to any object." Its meaning was clear enough once I got it, but I had to re-read it a couple of times to parse it correctly. Something about the passive voice plus the way "reference to any object" is split up by the verb phrase. How about this instead?
These are superfluous now that we have fixed rvalue lifetimes and Deref.
I'd also like to kill off `get` and `set`, but that'll be a large change so I want to make sure that we actually want to do that first.
These methods can be mistaken for general "read some bytes" utilities when
they're actually only meant for reading an exact number of bytes. By renaming
them it's much clearer about what they're doing without having to read the
documentation.
Closes#12892
Replace syntax::opt_vec with syntax::owned_slice
The `owned_slice::OwnedSlice` is `(*T, uint)` (i.e. a direct equivalent to DSTs `~[T]`).
This shaves two words off the old OptVec type; and also makes substituting in other implementations easy, by removing all the mutation methods. (And also everything that's very rarely/never used.)
The compiler will no longer inject libgreen as the default runtime for rust
programs, this commit switches it over to libnative by default. Now that
libnative has baked for some time, it is ready enough to start getting more
serious usage as the default runtime for rustc generated binaries.
We've found that there isn't really a correct decision in choosing a 1:1 or M:N
runtime as a default for all applications, but it seems that a larger number of
programs today would work more reasonably with a native default rather than a
green default.
With this commit come a number of bugfixes:
* The main native task is now named `<main>`
* The main native task has the stack bounds set up properly
* #[no_uv] was renamed to #[no_start]
* The core-run-destroy test was rewritten for both libnative and libgreen and
one of the tests was modified to be more robust.
* The process-detach test was locked to libgreen because it uses signal handling
If the dwShareMode parameter is 0 on windows, it "prevents other processes from
opening a file or device if they request delete, read, or write access", which
is the opposite of what we want! This changes the 0 parameter to something which
will allow multiple processes to open the file and then lock it.
The only stage that can be installed from is 2 everywhere but windows,
3 on windows.
Lightly tested. Not actually tested on Windows, but I did confirm that a *similar* change fixed the problem on Windows.
Closes#12799
The details can be found in the comment I wrote on the block in question, but
the gist of it is that our usage of the TIB for a stack limit was causing
CryptAcquireContext to fail, so we temporarily get around it by setting the
stack limit to 0.
The compiler will no longer inject libgreen as the default runtime for rust
programs, this commit switches it over to libnative by default. Now that
libnative has baked for some time, it is ready enough to start getting more
serious usage as the default runtime for rustc generated binaries.
We've found that there isn't really a correct decision in choosing a 1:1 or M:N
runtime as a default for all applications, but it seems that a larger number of
programs today would work more reasonable with a native default rather than a
green default.
With this commit come a number of bugfixes:
* The main native task is now named "<main>"
* The main native task has the stack bounds set up properly
* #[no_uv] was renamed to #[no_start]
* The core-run-destroy test was rewritten for both libnative and libgreen and
one of the tests was modified to be more robust.
* The process-detach test was locked to libgreen because it uses signal handling
If the dwShareMode parameter is 0 on windows, it "prevents other processes from
opening a file or device if they request delete, read, or write access", which
is the opposite of what we want! This changes the 0 parameter to something which
will allow multiple processes to open the file and then lock it.
test: Remove all `~[T]` from tests, libgetopts, compiletest, librustdoc, and libnum
And most from libtest, libflate, and adds `deny(deprecated_owned_vector)`s to the smaller modules with that have zero (or nearly zero) uses of `~[T]`.
Revival of #12837
This is a stand-in until we have a saner `~[T]` type (i.e. a proper
owned slice). It's a library version of what `~[T]` will be, i.e. an
owned pointer and a length.
Previously
trace_macros!(true)
fn main() {}
would complain about `trace_macros` being an expression macro in item
position. This is a pointless limitation, because the macro is purely
compile-time, with no runtime effect. (And similarly for log_syntax.)
This also changes the behaviour of `trace_macros!` very slightly, it
used to be equivalent to
macro_rules! trace_macros {
(true $($_x: tt)*) => { true };
(false $($_x: tt)*) => { false }
}
I.e. you could invoke it with arbitrary trailing arguments, which were
ignored. It is changed to accept only exactly `true` or `false` (with no
trailing arguments) and expands to `()`.
This should prevent lot of doc errors in Rust's buildbot and it shouldn't take long to run on travis. We could probably limit it to `std` but I preferred to just check all docs in this phase too.
@alexcrichton r?
This will require a snapshot to finish, but these commits update the parser to parse attributes of the form `#![...]`
Thanks to @TheHydroImpulse for all the initial work!
cc #2569
These methods can be mistaken for general "read some bytes" utilities when
they're actually only meant for reading an exact number of bytes. By renaming
them it's much clearer about what they're doing without having to read the
documentation.
Closes#12892
