The rust compiler not only outputs symbols in the form that C++ does, but it
also mangle symbols like '&' and '~' to special compiler-defined escape
sequences. For convenience, these symbols are demangled when printing
backtraces.
This is something that is plausibly useful, and is provided by libuv. This is
not currently surfaced as part of the `TcpStream` type, but it may possibly
appear in the future. For now only the raw functionality is provided through the
Rtio objects.
The old 'while' needed to match 2 times for each iteration. With the new
'loop' there is just one match needed.
I have also replaced 'blk' by 'f' to be more consistent with parameter
names in other functions that are implemented for Option
As mentioned in #6109, ```mkdir_recursive``` doesn't really need to use recursive calls, so here is an iterative version.
The other points of the proposed overhaul (renaming and existing permissions) still need to be resolved.
I also bundled an iterative ```rmdir_recursive```, for the same reason.
Please do not hesitate to provide feedback on style as this is my first code change in rust.
Added common and simple case folding, i.e. mapping one to one character mapping. For more information see http://www.unicode.org/faq/casemap_charprop.html
Removed auto-generated dead code which wasn't used.
For the following code snippet:
```rust
struct Foo { bar: int }
fn foo1(x: &Foo) -> &int {
&x.bar
}
```
This PR generates the following error message:
```rust
test.rs:2:1: 4:2 note: consider using an explicit lifetime parameter as shown: fn foo1<'a>(x: &'a Foo) -> &'a int
test.rs:2 fn foo1(x: &Foo) -> &int {
test.rs:3 &x.bar
test.rs:4 }
test.rs:3:5: 3:11 error: cannot infer an appropriate lifetime for borrow expression due to conflicting requirements
test.rs:3 &x.bar
^~~~~~
```
Currently it does not support methods.
Enables the dereference overloads introduced by #12491 to be applied wherever automatic dereferences would be used (field accesses, method calls and indexing).
Whenever a failure happens, if a program is run with
`RUST_LOG=std::rt::backtrace` a backtrace will be printed to the task's stderr
handle. Stack traces are uncondtionally printed on double-failure and
rtabort!().
This ended up having a nontrivial implementation, and here's some highlights of
it:
* We're bundling libbacktrace for everything but OSX and Windows
* We use libgcc_s and its libunwind apis to get a backtrace of instruction
pointers
* On OSX we use dladdr() to go from an instruction pointer to a symbol
* On unix that isn't OSX, we use libbacktrace to get symbols
* Windows, as usual, has an entirely separate implementation
Lots more fun details and comments can be found in the source itself.
Closes#10128
Whenever a failure happens, if a program is run with
`RUST_LOG=std::rt::backtrace` a backtrace will be printed to the task's stderr
handle. Stack traces are uncondtionally printed on double-failure and
rtabort!().
This ended up having a nontrivial implementation, and here's some highlights of
it:
* We're bundling libbacktrace for everything but OSX and Windows
* We use libgcc_s and its libunwind apis to get a backtrace of instruction
pointers
* On OSX we use dladdr() to go from an instruction pointer to a symbol
* On unix that isn't OSX, we use libbacktrace to get symbols
* Windows, as usual, has an entirely separate implementation
Lots more fun details and comments can be found in the source itself.
Closes#10128
Most IO related functions return an IoResult so that the caller can handle failure in whatever way is appropriate. However, the `lines`, `bytes`, and `chars` iterators all supress errors. This means that code that needs to handle errors can't use any of these iterators. All three of these iterators were updated to produce IoResults.
Fixes#12368
Most IO related functions return an IoResult so that the caller can handle failure
in whatever way is appropriate. However, the `lines`, `bytes`, and `chars` iterators all
supress errors. This means that code that needs to handle errors can't use any of these
iterators. All three of these iterators were updated to produce IoResults.
Fixes#12368
The `~str` type is not long for this world as it will be superseded by the
soon-to-come DST changes for the language. The new type will be
`~Str`, and matching over the allocation will no longer be supported.
Matching on `&str` will continue to work, in both a pre and post DST world.
The assertion was erroneously ensuring that there was no data on the port when
the port had selection aborted on it. This assertion was written in error
because it's possible for data to be waiting on a port, even after it was
disconnected. When aborting selection, if we see that there's data on the port,
then we return true that data is available on the port.
Closes#12802
This should be called far less than it is because it does expensive OS
interactions and seeding of the internal RNG, `task_rng` amortises this
cost. The main problem is the name is so short and suggestive.
The direct equivalent is `StdRng::new`, which does precisely the same
thing.
The deprecation will make migrating away from the function easier.
This replaces it with a manual "task rng" using XorShift and a crappy
seeding mechanism. Theoretically good enough for the purposes
though (unique for tests).
This functionality is not super-core and so doesn't need to be included
in std. It's possible that std may need rand (it does a little bit now,
for io::test) in which case the functionality required could be moved to
a secret hidden module and reexposed by librand.
Unfortunately, using #[deprecated] here is hard: there's too much to
mock to make it feasible, since we have to ensure that programs still
typecheck to reach the linting phase.
It is often convenient to have forms of weak linkage or other various types of
linkage. Sadly, just using these flavors of linkage are not compatible with
Rust's typesystem and how it considers some pointers to be non-null.
As a compromise, this commit adds support for weak linkage to external symbols,
but it requires that this is only placed on extern statics of type `*T`.
Codegen-wise, we get translations like:
```rust
// rust code
extern {
#[linkage = "extern_weak"]
static foo: *i32;
}
// generated IR
@foo = extern_weak global i32
@_some_internal_symbol = internal global *i32 @foo
```
All references to the rust value of `foo` then reference `_some_internal_symbol`
instead of the symbol `_foo` itself. This allows us to guarantee that the
address of `foo` will never be null while the value may sometimes be null.
An example was implemented in `std::rt::thread` to determine if
`__pthread_get_minstack()` is available at runtime, and a test is checked in to
use it for a static value as well. Function pointers a little odd because you
still need to transmute the pointer value to a function pointer, but it's
thankfully better than not having this capability at all.
Thanks to @bnoordhuis for the original patch, most of this work is still his!
It is often convenient to have forms of weak linkage or other various types of
linkage. Sadly, just using these flavors of linkage are not compatible with
Rust's typesystem and how it considers some pointers to be non-null.
As a compromise, this commit adds support for weak linkage to external symbols,
but it requires that this is only placed on extern statics of type `*T`.
Codegen-wise, we get translations like:
// rust code
extern {
#[linkage = "extern_weak"]
static foo: *i32;
}
// generated IR
@foo = extern_weak global i32
@_some_internal_symbol = internal global *i32 @foo
All references to the rust value of `foo` then reference `_some_internal_symbol`
instead of the symbol `_foo` itself. This allows us to guarantee that the
address of `foo` will never be null while the value may sometimes be null.
An example was implemented in `std::rt::thread` to determine if
`__pthread_get_minstack()` is available at runtime, and a test is checked in to
use it for a static value as well. Function pointers a little odd because you
still need to transmute the pointer value to a function pointer, but it's
thankfully better than not having this capability at all.
Where ItemDecorator creates new items given a single item, ItemModifier
alters the tagged item in place. The expansion rules for this are a bit
weird, but I think are the most reasonable option available.
When an item is expanded, all ItemModifier attributes are stripped from
it and the item is folded through all ItemModifiers. At that point, the
process repeats until there are no ItemModifiers in the new item.
This is mostly a reaction to #12730. If we are going to keep calling them `char`, at least make it clear that they aren't characters but codepoint/scalar.
This seems to be causing some confusion among users. Rust's char are
not 8bit characters, but 32bit UCS-4 codepoint without surrogates
(Unicode Scalar Values as per Unicode glossary).
Make the doc more explicit about it.
Signed-off-by: Luca Bruno <lucab@debian.org>
* `Ord` inherits from `Eq`
* `TotalOrd` inherits from `TotalEq`
* `TotalOrd` inherits from `Ord`
* `TotalEq` inherits from `Eq`
This is a partial implementation of #12517.
If no arguments are given to `vec!` then no pushes are emitted and
so the compiler (rightly) complains that the mutability of `temp` is
never used.
This behaviour is rather annoying for users.
When using tasks in Rust, the expectation is that the runtime does not exit
before all tasks have exited. This is enforced in libgreen through the
`SchedPool` type, and it is enforced in libnative through a `bookkeeping` module
and a global count/mutex pair. Unfortunately, this means that a process which
originates with libgreen will not wait for spawned native tasks.
In order to fix this problem, the bookkeeping module was moved from libnative to
libstd so the runtime itself can wait for native tasks to exit. Green tasks do
not manage themselves through this bookkeeping module, but native tasks will
continue to manage themselves through this module.
Closes#12684
Using nanosleep() allows us to gracefully recover from EINTR because on error it
fills in the second parameter with the remaining time to sleep.
Closes#12689
The `std::cmp` functions are not correct for floating point types.
`min(NaN, 2.0)` and `min(2.0, NaN)` return different values, because
these functions assume a total order. Floating point types need special
`min`, `max` and `clamp` functions.
I added a new lint for variables whose names contain uppercase characters, since, by convention, variable names should be all lowercase. What motivated me to work on this was when I ran into something like the following:
```rust
use std::io::File;
use std::io::IoError;
fn main() {
let mut f = File::open(&Path::new("/something.txt"));
let mut buff = [0u8, ..16];
match f.read(buff) {
Ok(cnt) => println!("read this many bytes: {}", cnt),
Err(IoError{ kind: EndOfFile, .. }) => println!("Got end of file: {}", EndOfFile.to_str()),
}
}
```
I then got compile errors when I tried to add a wildcard match pattern at the end which I found very confusing since I believed that the 2nd match arm was only matching the EndOfFile condition. The problem is that I hadn't imported io::EndOfFile into the local scope. So, I thought that I was using EndOfFile as a sub-pattern, however, what I was actually doing was creating a new local variable named EndOfFile. This lint makes this error easier to spot by providing a warning that the variable name EndOfFile contains a uppercase characters which provides a nice hint as to why the code isn't doing what is intended.
The lint warns on local bindings as well:
```rust
let Hi = 0;
```
And also struct fields:
```rust
struct Something {
X: uint
}
```
- Added `TraitObject` representation to `std::raw`.
- Added doc to `std::raw`.
- Removed `Any::as_void_ptr()` and `Any::as_mut_void_ptr()`
methods as they are uneccessary now after the removal of
headers on owned boxes. This reduces the number of virtual calls needed from 2 to 1.
- Made the `..Ext` implementations work directly with the repr of
a trait object.
- Removed `Any`-related traits from the prelude.
- Added bench.
Bench before/after:
~~~
7 ns/iter (+/- 0)
4 ns/iter (+/- 0)
~~~
- Added `TraitObject` representation to `std::raw`.
- Added doc to `std::raw`.
- Removed `Any::as_void_ptr()` and `Any::as_mut_void_ptr()`
methods as they are uneccessary now after the removal of
headers on owned boxes. This reduces the number of virtual calls needed.
- Made the `..Ext` implementations work directly with the repr of
a trait object.
- Removed `Any`-related traits from the prelude.
- Added bench for `Any`
Similarly to #12422 which made stdin buffered by default, this commit makes the
output streams also buffered by default. Now that buffered writers will flush
their contents when they are dropped, I don't believe that there's no reason why
the output shouldn't be buffered by default, which is what you want in 90% of
cases.
As with stdin, there are new stdout_raw() and stderr_raw() functions to get
unbuffered streams to stdout/stderr.
It's still not entirely clear what should happen if there was an error when
flushing, but I'm deferring that decision to #12628. I believe that it's crucial
for the usefulness of buffered writers to be able to flush on drop. It's just
too easy to forget to flush them in small one-off use cases.
cc #12628
Formatting via reflection has been a little questionable for some time now, and
it's a little unfortunate that one of the standard macros will silently use
reflection when you weren't expecting it. This adds small bits of code bloat to
libraries, as well as not always being necessary. In light of this information,
this commit switches assert_eq!() to using {} in the error message instead of
{:?}.
In updating existing code, there were a few error cases that I encountered:
* It's impossible to define Show for [T, ..N]. I think DST will alleviate this
because we can define Show for [T].
* A few types here and there just needed a #[deriving(Show)]
* Type parameters needed a Show bound, I often moved this to `assert!(a == b)`
* `Path` doesn't implement `Show`, so assert_eq!() cannot be used on two paths.
I don't think this is much of a regression though because {:?} on paths looks
awful (it's a byte array).
Concretely speaking, this shaved 10K off a 656K binary. Not a lot, but sometime
significant for smaller binaries.
I've been playing around with code size when linking to libstd recently, and these were some findings I found that really helped code size. I started out by eliminating all I/O implementations from libnative and instead just return an unimplemented error.
In doing so, a `fn main() {}` executable was ~378K before this patch, and about 170K after the patch. These size wins are all pretty minor, but they all seemed pretty reasonable to me. With native I/O not stubbed out, this takes the size of an LTO executable from 675K to 400K.
This function is a tiny wrapper that LLVM doesn't want to inline, and it ends up
causing more bloat than necessary. The bloat is pretty small, but it's a win of
at least 7k for small executables, and I imagine that the number goes up as
there are more calls to fail!().
This removes all usage of Poly in format strings from libstd. This doesn't
prevent more future strings from coming in, but it at least removes the ones for
now.
Most of these are unnecessary because we're only looking at static strings. This
also moves to Vec in a few places instead of ~[T].
This didn't end up getting much of a code size win (update_log_settings is the
third largest function in the executables I'm looking at), but this seems like a
generally nice improvement regardless.
This lowers the #[allow(missing_doc)] directive into some of the lower modules
which are less mature. Most I/O modules now require comprehensive documentation.
This is a ubiquitous type in concurrent code, and the assertions are causing
significant code bloat for simple operations such as reading the pointer
(injecting a failure point, etc).
I am testing executable sizes with no I/O implementations (everything stubbed
out to return nothing), and this took the size of a libnative executable from
328K to 207K (37% reduction in size), so I think that this is one assertion
that's well worth configuring off for now.
There's a lot of these types in the compiler libraries, and a few of the
older or private stdlib ones. Some types are obviously meant to be
public, others not so much.
This PR allows `HashMap`s to work with custom hashers. Also with this patch are:
* a couple generic implementations of `Hash` for a variety of types.
* added `Default`, `Clone` impls to the hashers.
* added a `HashMap::with_hasher()` constructor.
Closes#12546 (Add new target 'make dist-osx' to create a .pkg installer for OS X) r=brson
Closes#12575 (rustc: Move local native libs back in link-args) r=brson
Closes#12587 (Provide a more helpful error for tests that fail due to noexec) r=brson
Closes#12589 (rustc: Remove codemap and reachable from metadata encoder) r=alexcrichton
Closes#12591 (Fix syntax::ext::deriving{,::*} docs formatting.) r=huonw
Closes#12592 (Miscellaneous Vim improvements) r=alexcrichton
Closes#12596 (path: Implement windows::make_non_verbatim()) r=alexcrichton
Closes#12598 (Improve the ctags function regular expression) r=alexcrichton
Closes#12599 (Tutorial improvement (new variant of PR #12472).) r=pnkfelix
Closes#12603 (std: Export the select! macro) r=pcwalton
Closes#12605 (Fix typo in doc of Binary trait in std::fmt) r=alexcrichton
Closes#12613 (Fix bytepos_to_file_charpos) r=brson
This PR includes:
- Create an iterator for ```List<T>``` called ```Items<T>```;
- Move all list operations inside ```List<T>``` impl;
- Removed functions that are already provided by ```Iterator``` trait;
- Refactor on ```len()``` and ```is_empty``` using ```Container``` trait;
- Bunch of minor fixes;
A replacement for using @ is intended, but still in discussion.
Closes#12344.
Mark it as #[experimental] for now. In theory this attribute will be read in the
future. I believe that the implementation is solid enough for general use,
although I would not be surprised if there were bugs in it still. I think that
it's at the point now where public usage of it will start to uncover hopefully
the last few remaining bugs.
Closes#12044
Get rid of the unnecessary parenthesies that crept into some macros.
Remove a FIXME that was already fixed.
Fix a comment that wasn't rendering correctly in rustdoc.
The compiler itself doesn't necessarily need any features of green threading
such as spawning tasks and lots of I/O, so libnative is slightly more
appropriate for rustc to use itself.
This should also help the rusti bot which is currently incompatible with libuv.
This commit splits the file implementation into file_unix and file_win32. The
two implementations have diverged to the point that they share almost 0 code at
this point, so it's easier to maintain as separate files.
The other major change accompanied with this commit is that file::open is no
longer based on libc's open function on windows, but rather windows's CreateFile
function. This fixes dealing with binary files on windows (test added in
previous commit).
This also changes the read/write functions to use ReadFile and WriteFile instead
of libc's read/write.
Closes#12406
This weeds out a bunch of warnings building stdtest on windows, and it also adds
a check! macro to the io::fs tests to help diagnose errors that are cropping up
on windows platforms as well.
cc #12516
The printing of the error message on stack overflow had two sometimes false
assumptions previously. The first is that a local task was always available (it
called Local::take) and the second is that it used `println!` instead of
manually writing.
The first assumption isn't necessarily true because while stack overflow will
likely only be detected in situations that a local task is available, it's not
guaranteed to always be in TLS. For example, during a `println!` call a task
may be blocking, causing it to be unavailable. By using Local::try_take(), we
can be resilient against these occurrences.
The second assumption could lead to odd behavior because the stdout logger can
be overwritten to run arbitrary code. Currently this should be possible, but the
utility is much diminished because a stack overflow translates to an abort()
instead of a failure.
The printing of the error message on stack overflow had two sometimes false
assumptions previously. The first is that a local task was always available (it
called Local::take) and the second is that it used println! instead of
manually writing.
The first assumption isn't necessarily true because while stack overflow will
likely only be detected in situations that a local task is available, it's not
guaranteed to always be in TLS. For example, during a println! call a task
may be blocking, causing it to be unavailable. By using Local::try_take(), we
can be resilient against these occurrences.
The second assumption could lead to odd behavior because the stdout logger can
be overwritten to run arbitrary code. Currently this should be possible, but the
utility is much diminished because a stack overflow translates to an abort()
instead of a failure.
Apparently weak linkage and dlopen aren't quite working out for applications
like servo on android. There appears to be a bug or two in how android loads
dynamic libraries and for some reason libservo.so isn't being found.
As a temporary solution, add an extern "C" function to libstd which can be
called if you have a handle to the crate map manually. When crawling the crate
map, we then check this manual symbol before falling back to the old solutions.
cc #11731
This patch series does a couple things:
* replaces manual `Hash` implementations with `#[deriving(Hash)]`
* adds `Hash` back to `std::prelude`
* minor cleanup of whitespace and variable names.
`.reserve_exact` can cause pathological O(n^2) behaviour, so providing a
`.reserve` that ensures that capacity doubles (if you step 1, 2, ..., n)
is more efficient.
cc #11949
Commits for details. Highlights:
- `flate` returns `CVec<u8>` to save reallocating a whole new `&[u8]`
- a lot of `transmute`s removed outright or replaced with `as` (etc.)
Turns out the `timeout` command was exiting immediately because it didn't like
its output piped. Instead use `ping` repeatedly to get a process that will sleep
for awhile.
cc #12516
These two tests are notoriously flaky on the windows bots right now, so I'm
ignoring them until I can investigate them some more. The truncate_works test
has been flaky for quite some time, but it has gotten much worse recently. The
test_exists test has been flaky since the recent std::run rewrite landed.
Finally, the "unix pipe" test failure is a recent discovery on the try bots. I
haven't seen this failing much, but better safe than sorry!
cc #12516
This commit removes deriving(ToStr) in favor of deriving(Show), migrating all impls of ToStr to fmt::Show.
Most of the details can be found in the first commit message.
Closes#12477
The std::run module is a relic from a standard library long since past, and
there's not much use to having two modules to execute processes with where one
is slightly more convenient. This commit merges the two modules, moving lots of
functionality from std::run into std::io::process and then deleting
std::run.
New things you can find in std::io::process are:
* Process::new() now only takes prog/args
* Process::configure() takes a ProcessConfig
* Process::status() is the same as run::process_status
* Process::output() is the same as run::process_output
* I/O for spawned tasks is now defaulted to captured in pipes instead of ignored
* Process::kill() was added (plus an associated green/native implementation)
* Process::wait_with_output() is the same as the old finish_with_output()
* destroy() is now signal_exit()
* force_destroy() is now signal_kill()
Closes#2625Closes#10016
The std::run module is a relic from a standard library long since past, and
there's not much use to having two modules to execute processes with where one
is slightly more convenient. This commit merges the two modules, moving lots of
functionality from std::run into std::io::process and then deleting
std::run.
New things you can find in std::io::process are:
* Process::new() now only takes prog/args
* Process::configure() takes a ProcessConfig
* Process::status() is the same as run::process_status
* Process::output() is the same as run::process_output
* I/O for spawned tasks is now defaulted to captured in pipes instead of ignored
* Process::kill() was added (plus an associated green/native implementation)
* Process::wait_with_output() is the same as the old finish_with_output()
* destroy() is now signal_exit()
* force_destroy() is now signal_kill()
Closes#2625Closes#10016
This commit changes the ToStr trait to:
impl<T: fmt::Show> ToStr for T {
fn to_str(&self) -> ~str { format!("{}", *self) }
}
The ToStr trait has been on the chopping block for quite awhile now, and this is
the final nail in its coffin. The trait and the corresponding method are not
being removed as part of this commit, but rather any implementations of the
`ToStr` trait are being forbidden because of the generic impl. The new way to
get the `to_str()` method to work is to implement `fmt::Show`.
Formatting into a `&mut Writer` (as `format!` does) is much more efficient than
`ToStr` when building up large strings. The `ToStr` trait forces many
intermediate allocations to be made while the `fmt::Show` trait allows
incremental buildup in the same heap allocated buffer. Additionally, the
`fmt::Show` trait is much more extensible in terms of interoperation with other
`Writer` instances and in more situations. By design the `ToStr` trait requires
at least one allocation whereas the `fmt::Show` trait does not require any
allocations.
Closes#8242Closes#9806
This adds simple syntax highlighting based off libsyntax's lexer to be sure to
stay up to date with rust's grammar. Some of the highlighting is a bit ad-hoc,
but it definitely seems to get the job done!
This currently doesn't highlight rustdoc-rendered function signatures and
structs that are emitted to each page because the colors already signify what's
clickable and I think we'd have to figure out a different scheme before
colorizing them. This does, however, colorize all code examples and source code.
Closes#11393
With the stability attributes we can put public-but unstable modules next to others, so this moves `intrinsics` and `raw` out of the `unstable` module (and marks both as `#[experimental]`).
These two containers are indeed collections, so their place is in
libcollections, not in libstd. There will always be a hash map as part of the
standard distribution of Rust, but by moving it out of the standard library it
makes libstd that much more portable to more platforms and environments.
This conveniently also removes the stuttering of 'std::hashmap::HashMap',
although 'collections::HashMap' is only one character shorter.
This adds simple syntax highlighting based off libsyntax's lexer to be sure to
stay up to date with rust's grammar. Some of the highlighting is a bit ad-hoc,
but it definitely seems to get the job done!
This currently doesn't highlight rustdoc-rendered function signatures and
structs that are emitted to each page because the colors already signify what's
clickable and I think we'd have to figure out a different scheme before
colorizing them. This does, however, colorize all code examples and source code.
Closes#11393
This PR merges `IterBytes` and `Hash` into a trait that allows for generic non-stream-based hashing. It makes use of @eddyb's default type parameter support in order to have a similar usage to the old `Hash` framework.
Fixes#8038.
Todo:
- [x] Better documentation
- [ ] Benchmark
- [ ] Parameterize `HashMap` on a `Hasher`.
Closes#12366.
Parentheses around assignment statements such as
let mut a = (0);
a = (1);
a += (2);
are not necessary and therefore an unnecessary_parens warning is raised when
statements like this occur.
The warning mechanism was refactored along the way to allow for code reuse
between the routines for checking expressions and statements.
Code had to be adopted throughout the compiler and standard libraries to comply
with this modification of the lint.
One of the most common ways to use the stdin stream is to read it line by line
for a small program. In order to facilitate this common usage pattern, this
commit changes the stdin() function to return a BufferedReader by default. A new
`stdin_raw()` method was added to get access to the raw unbuffered stream.
I have not changed the stdout or stderr methods because they are currently
unable to flush in their destructor, but #12403 should have just fixed that.
This patch merges IterBytes and Hash traits, which clears up the
confusion of using `#[deriving(IterBytes)]` to support hashing.
Instead, it now is much easier to use the new `#[deriving(Hash)]`
for making a type hashable with a stream hash.
Furthermore, it supports custom non-stream-based hashers, such as
if a value's hash was cached in a database.
This does not yet replace the old IterBytes-hash with this new
version.
This is PR is the beginning of a complete rewrite and ultimate removal of the `std::num::strconv` module (see #6220), and the removal of the `ToStrRadix` trait in favour of using the `std::fmt` functionality directly. This should make for a cleaner API, encourage less allocation, and make the implementation more comprehensible .
The `Formatter::{pad_integral, with_padding}` methods have also been refactored make things easier to understand.
The formatting tests for integers have been moved out of `run-pass/ifmt.rs` in order to provide more immediate feedback when building using `make check-stage2-std NO_REBUILD=1`.
Arbitrary radixes are now easier to use in format strings. For example:
~~~rust
assert_eq!(format!("{:04}", radix(3, 2)), ~"0011");
~~~
The benchmarks have been standardised between `std::num::strconv` and `std::num::fmt` to make it easier to compare the performance of the different implementations.
~~~
type | radix | std::num::strconv | std::num::fmt
======|=======|========================|======================
int | bin | 1748 ns/iter (+/- 150) | 321 ns/iter (+/- 25)
int | oct | 706 ns/iter (+/- 53) | 179 ns/iter (+/- 22)
int | dec | 640 ns/iter (+/- 59) | 207 ns/iter (+/- 10)
int | hex | 637 ns/iter (+/- 77) | 205 ns/iter (+/- 19)
int | 36 | 446 ns/iter (+/- 30) | 309 ns/iter (+/- 20)
------|-------|------------------------|----------------------
uint | bin | 1724 ns/iter (+/- 159) | 322 ns/iter (+/- 13)
uint | oct | 663 ns/iter (+/- 25) | 175 ns/iter (+/- 7)
uint | dec | 613 ns/iter (+/- 30) | 186 ns/iter (+/- 6)
uint | hex | 519 ns/iter (+/- 44) | 207 ns/iter (+/- 20)
uint | 36 | 418 ns/iter (+/- 16) | 308 ns/iter (+/- 32)
~~~
This is in preparation to remove the implementations of ToStrRadix in integers, and to remove the associated logic from `std::num::strconv`.
The parts that still need to be liberated are:
- `std::fmt::Formatter::runplural`
- `num::{bigint, complex, rational}`
This works towards a complete rewrite and ultimate removal of the `std::num::strconv` module (see #6220), and the removal of the `ToStrRadix` trait in favour of using the `std::fmt` functionality directly. This should make for a cleaner API, encourage less allocation, and make the implementation far more comprehensible.
The `Formatter::pad_integral` method has also been refactored make it easier to understand.
The formatting tests for integers have been moved out of `run-pass/ifmt.rs` in order to provide more immediate feedback when building using `make check-stage2-std NO_REBUILD=1`.
The benchmarks have been standardised between std::num::strconv and std::num::fmt to make it easier to compare the performance of the different implementations.
Arbitrary radixes are now easier to use in format strings. For example:
~~~
assert_eq!(format!("{:04}", radix(3, 2)), ~"0011");
~~~
ptr::RawPtr, spell out units used for the `offset` argument.
spell out units used for the `offset` argument, so that callers do not
try to scale to byte units themselves.
(this was originally landed in PR #11002 for the stand-alone functions, but that PR did not modify the `RawPtr` methods, since that had no doc at all at the time. Now `RawPtr` has the *only* documentation for `offset`, since the stand-alone functions went away in PR #12167 / PR #12248.)
Previously an `unsafe` block created by the compiler (like those in the
formatting macros) would be "ignored" if surrounded by `unsafe`, that
is, the internal unsafety would be being legitimised by the external
block:
unsafe { println!("...") } =(expansion)=> unsafe { ... unsafe { ... } }
And the code in the inner block would be using the outer block, making
it considered used (and the inner one considered unused).
This patch forces the compiler to create a new unsafe context for
compiler generated blocks, so that their internal unsafety doesn't
escape to external blocks.
Fixes#12418.
The comments say that the prelude imports std::io::println since it would
be annoying to have to import it in every program that uses it. However,
the prelude doesn't actually import that function anymore. So, update the
comments to better match reality.
This "bubble up an error" macro was originally named if_ok! in order to get it
landed, but after the fact it was discovered that this name is not exactly
desirable.
The name `if_ok!` isn't immediately clear that is has much to do with error
handling, and it doesn't look fantastic in all contexts (if if_ok!(...) {}). In
general, the agreed opinion about `if_ok!` is that is came in as subpar.
The name `try!` is more invocative of error handling, it's shorter by 2 letters,
and it looks fitting in almost all circumstances. One concern about the word
`try!` is that it's too invocative of exceptions, but the belief is that this
will be overcome with documentation and examples.
Close#12037
One of the most common ways to use the stdin stream is to read it line by line
for a small program. In order to facilitate this common usage pattern, this
commit changes the stdin() function to return a BufferedReader by default. A new
`stdin_raw()` method was added to get access to the raw unbuffered stream.
I have not changed the stdout or stderr methods because they are currently
unable to flush in their destructor, but #12403 should have just fixed that.
Previously an `unsafe` block created by the compiler (like those in the
formatting macros) would be "ignored" if surrounded by `unsafe`, that
is, the internal unsafety would be being legitimised by the external
block:
unsafe { println!("...") } =(expansion)=> unsafe { ... unsafe { ... } }
And the code in the inner block would be using the outer block, making
it considered used (and the inner one considered unused).
This patch forces the compiler to create a new unsafe context for
compiler generated blocks, so that their internal unsafety doesn't
escape to external blocks.
Fixes#12418.
The fairness yield mistakenly called `Local::take()` which meant that it would
only work if a local task was available. In theory sending on a channel (or calling try_recv) requires
no runtime because it never blocks, so there's no reason it shouldn't support
such a use case.
Closes#12391
I don't think `extra` is a good/meaningful name for a library. `libextra` should disappear, and we move all of its sub modules out of it. This PR is just one of that steps: move `extra::test` to `libtest`.
I didn't add `libtest` to doc index, because it's an internal library currently.
**Update:**
All comments addressed. All tests passed. Rebased and squashed.
On windows, the GetEnvironmentVariable function will return the necessary buffer
size if the buffer provided was too small. This case previously fell through the
checks inside of fill_utf16_buf_and_decode, tripping an assertion in the `slice`
method.
This adds an extra case for when the return value is >= the buffer size, in
which case we assume the return value as the new buffer size and try again.
Closes#12376
The comments say that the prelude imports std::io::println since it would
be annoying to have to import it in every program that uses it. However,
the prelude doesn't actually import that function anymore. So, update the
comments to better match reality.
The fairness yield mistakenly called `Local::take()` which meant that it would
only work if a local task was available. In theory sending on a channel (or
calling try_recv) requires no runtime because it never blocks, so there's no
reason it shouldn't support such a use case.
Closes#12391
On windows, the GetEnvironmentVariable function will return the necessary buffer
size if the buffer provided was too small. This case previously fell through the
checks inside of fill_utf16_buf_and_decode, tripping an assertion in the `slice`
method.
This adds an extra case for when the return value is >= the buffer size, in
which case we assume the return value as the new buffer size and try again.
Closes#12376
Any macro tagged with #[macro_export] will be showed in the documentation for
that module. This also documents all the existing macros inside of std::macros.
Closes#3163
cc #5605Closes#9954
Iterators! Use them (in `is_utf16`), create them (in `utf16_items`).
Handle errors gracefully (`from_utf16_lossy`) and `from_utf16` returning `Option<~str>` instead of failing.
Add a pile of tests.
Many of the functions interacting with Windows APIs allocate a vector of
0's and do not retrieve a length directly from the API call, and so need
to be sure to remove the unmodified junk at the end of the vector.
See the commit messages for more details, but this makes `std::str::is_utf8` slightly faster and 100% non-`unsafe` and uses a similar thing to make the first scan of `from_utf8_lossy` 100% safe & faster.
This uses a vector iterator to avoid the necessity for unsafe indexing,
and makes this function slightly faster. Unfortunately #11751 means that
the iterator comes with repeated `null` checks which means the
pure-ASCII case still has room for significant improvement (and the
other cases too, but it's most significant for just ASCII).
Before:
is_utf8_100_ascii ... bench: 143 ns/iter (+/- 6)
is_utf8_100_multibyte ... bench: 134 ns/iter (+/- 4)
After:
is_utf8_100_ascii ... bench: 123 ns/iter (+/- 4)
is_utf8_100_multibyte ... bench: 115 ns/iter (+/- 5)
There's a few parts to this PR
* Implement unix pipes in libnative for unix platforms (thanks @Geal!)
* Implement named pipes in libnative for windows (terrible, terrible code)
* Remove `#[cfg(unix)]` from `mod unix` in `std::io::net`. This is a terrible name for what it is, but that's the topic of #12093.
The windows implementation was significantly more complicated than I thought it would be, but it seems to be passing all the tests. now.
Closes#11201
Delete all the documentation from std::task that references linked
failure.
Tweak TaskBuilder to be more builder-like. `.name()` is now `.named()` and
`.add_wrapper()` is now `.with_wrapper()`. Remove `.watched()` and
`.unwatched()` as they didn't actually do anything.
Closes#6399.
This deadlock was caused when the channel was closed at just the right time, so
the extra `self.cnt.fetch_add` actually should have preserved the DISCONNECTED
state of the channel. by modifying this the channel entered a state such that
the port would never succeed in dropping.
This also moves the increment of self.steals until after the MAX_STEALS block.
The reason for this is that in 'fn recv()' the steals variable is decremented
immediately after the try_recv(), which could in theory set steals to -1 if it
was previously set to 0 in try_recv().
Closes#12340
This is inspired by the [function naming in the Julia standard library](http://docs.julialang.org/en/release-0.2/stdlib/base/#Base.count_ones). It seems like a more self-explanatory name, and is more consistent with the accompanying methods, `leading_zeros` and `trailing_zeros`.
This replaces the iterator with one that handles lone surrogates
gracefully and uses that to implement `from_utf16_lossy` which replaces
invalid `u16`s with U+FFFD.
* Implementation of pipe_win32 filled out for libnative
* Reorganize pipes to be clone-able
* Fix a few file descriptor leaks on error
* Factor out some common code into shared functions
* Make use of the if_ok!() macro for less indentation
Closes#11201
