bors [Tue, 25 Nov 2014 09:21:45 +0000 (09:21 +0000)]
auto merge of #19149 : alexcrichton/rust/issue-19091, r=aturon
This change applies the conventions to unwrap listed in [RFC 430][rfc] to rename
non-failing `unwrap` methods to `into_inner`. This is a breaking change, but all
`unwrap` methods are retained as `#[deprecated]` for the near future. To update
code rename `unwrap` method calls to `into_inner`.
bors [Tue, 25 Nov 2014 06:51:38 +0000 (06:51 +0000)]
auto merge of #18966 : huonw/rust/iter2slice, r=aturon
A slice iterator is isomorphic to a slice, just with a slightly
different form: storing start and end pointers rather than start pointer
and length. This patch reflects this by making converting between them
as easy as `iter.as_slice()` (or even `iter[]` if the shorter lifetime
is ok). That is, `slice.iter().as_slice() == slice`.
Huon Wilson [Sat, 15 Nov 2014 03:44:55 +0000 (14:44 +1100)]
Add methods to go from a slice iterators to a slice.
A slice iterator is isomorphic to a slice, just with a slightly
different form: storing start and end pointers rather than start pointer
and length. This patch reflects this by making converting between them
as easy as `iter.as_slice()` (or even `iter[]` if the shorter lifetime
is ok). That is, `slice.iter().as_slice() == slice`.
bors [Tue, 25 Nov 2014 01:06:41 +0000 (01:06 +0000)]
auto merge of #19285 : alexcrichton/rust/issue-19280, r=aturon
It turns out that rustrt::at_exit() doesn't actually occur after all pthread
threads have exited (nor does atexit()), so there's not actually a known point
at which we can deallocate these keys. It's not super critical that we do so,
however, because we're about to exit anyway!
Alex Crichton [Mon, 24 Nov 2014 23:24:29 +0000 (15:24 -0800)]
std: Leak all statically allocated TLS keys
It turns out that rustrt::at_exit() doesn't actually occur after all pthread
threads have exited (nor does atexit()), so there's not actually a known point
at which we can deallocate these keys. It's not super critical that we do so,
however, because we're about to exit anyway!
bors [Mon, 24 Nov 2014 23:06:45 +0000 (23:06 +0000)]
auto merge of #19021 : roysc/rust/emacs-pr, r=brson
"_" should keep the default syntax class (symbol, not word). This
allows, e.g., `forward-word' to behave in the familiar way, jumping to
underscores within a function or variable name.
bors [Mon, 24 Nov 2014 11:56:34 +0000 (11:56 +0000)]
auto merge of #19248 : japaric/rust/str, r=alexcrichton
Just like we do with AsSlice
This comes in handy when dealing with iterator-centric APIs (`IntoIterator`!) and you want to receive an `Iterator<S> where S: Str` argument. Without this PR, e.g. you can't receive `&["a", "b"].iter()` instead you'll have to type `&["a", "b"].iter().map(|&x| x)` (A similar thing happens with `&[String]`).
r? @aturon
Full disclaimer: I haven't run `make`/`make check` yet (All my cores are busy)
bors [Mon, 24 Nov 2014 09:56:34 +0000 (09:56 +0000)]
auto merge of #19094 : alexcrichton/rust/rm-std-local-data, r=aturon
This commit removes the `std::local_data` module in favor of a new `std::thread_local`
module providing thread local storage. The module provides two variants of TLS:
one which owns its contents and one which is based on scoped references. Each
implementation has pros and cons listed in the documentation.
Both flavors have accessors through a function called `with` which yield a
reference to a closure provided. Both flavors also panic if a reference cannot
be yielded and provide a function to test whether an access would panic or not.
This is an implementation of [RFC 461][rfc] and full details can be found in
that RFC.
This is a breaking change due to the removal of the `std::local_data` module.
All users can migrate to the new tls system like so:
The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as
an implementation detail which must now be explicitly stated by users.
bors [Mon, 24 Nov 2014 07:51:32 +0000 (07:51 +0000)]
auto merge of #19236 : csouth3/rust/master, r=Gankro
Whilst browsing the source for BinaryHeap, I saw a FIXME for implementing into_iter. I think, since the BinaryHeap is represented internally using just a Vec, just calling into_iter() on the BinaryHeap's data should be sufficient to do what we want here. If this actually isn't the right approach (e.g., I should write a struct MoveItems and appropriate implementation for BinaryHeap instead), let me know and I'll happily rework this.
Both of the tests that I have added pass. This is my first contribution to Rust, so please let me know any ways I can improve this PR!
Alex Crichton [Fri, 14 Nov 2014 22:20:57 +0000 (14:20 -0800)]
std: Add a new top-level thread_local module
This commit removes the `std::local_data` module in favor of a new
`std::thread_local` module providing thread local storage. The module provides
two variants of TLS: one which owns its contents and one which is based on
scoped references. Each implementation has pros and cons listed in the
documentation.
Both flavors have accessors through a function called `with` which yield a
reference to a closure provided. Both flavors also panic if a reference cannot
be yielded and provide a function to test whether an access would panic or not.
This is an implementation of [RFC 461][rfc] and full details can be found in
that RFC.
This is a breaking change due to the removal of the `std::local_data` module.
All users can migrate to the new thread local system like so:
The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as
an implementation detail which must now be explicitly stated by users.
Alex Crichton [Thu, 20 Nov 2014 17:23:43 +0000 (09:23 -0800)]
Rename unwrap functions to into_inner
This change applies the conventions to unwrap listed in [RFC 430][rfc] to rename
non-failing `unwrap` methods to `into_inner`. This is a breaking change, but all
`unwrap` methods are retained as `#[deprecated]` for the near future. To update
code rename `unwrap` method calls to `into_inner`.
Jakub Bukaj [Sun, 23 Nov 2014 19:12:01 +0000 (14:12 -0500)]
rollup merge of #19234: P1start/rustdoc-misc
This PR:
- makes rustdoc colour trait methods like other functions in search results;
- makes rustdoc display `extern crate` statements with the new `as` syntax instead of the old `=` syntax;
- changes rustdoc to list constants and statics in a way that is more similar to functions and modules and show their full definition and documentation on their own page, fixing #19046:
I would appreciate any guidance on how to write a test for this. I saw some examples in `test/pretty`, but there are different ways to test... With or without `.pp` files, with a `pp-exact` comment, etc.
Jakub Bukaj [Sun, 23 Nov 2014 19:11:54 +0000 (14:11 -0500)]
rollup merge of #19205: jashank/docs-fix
Catch a missed triple-slash in the docs for `std::os::args()`. Passes `make check`. (I've also eyeballed the rest of `libstd` with the aid of some funky regexes and haven't found anything similar.)
Jakub Bukaj [Sun, 23 Nov 2014 19:11:51 +0000 (14:11 -0500)]
rollup merge of #19194: aturon/stab-ascii
This is an initial API stabilization pass for `std::ascii`. Aside from
some renaming to match conversion conventions, and deprecations in favor
of using iterators directly, almost nothing is changed here. However,
the static case conversion tables that were previously public are now private.
The stabilization of the (rather large!) set of extension traits is left
to a follow-up pass, because we hope to land some more general machinery
that will provide the same functionality without custom traits.
Jakub Bukaj [Sun, 23 Nov 2014 19:11:50 +0000 (14:11 -0500)]
rollup merge of #19193: scialex/rc-counts
These functions allow you to see how many weak and strong references
there are to an `Arc`, `Rc`, or an `rc::Weak`. Due to the design of
`Arc` it is not possible to get the number of weak references of an
arbitrary `arc::Weak`. Look in `arc.rs` for a more in-depth explanation.
On `arc::Arc` and `arc::Weak` these operations are wait-free and atomic.
This sort of information is useful for creating dynamically cleared caches for use in OS development, for example holding pages of files in memory until the address space is needed for something else.
bors [Sun, 23 Nov 2014 13:51:47 +0000 (13:51 +0000)]
auto merge of #18140 : JelteF/rust-1/guide-fix, r=cmr
The reason given didn't make any sense when I read it when reading through the docs. I think this is more clear. Please let me know it is also more correct.
NODA, Kai [Sun, 23 Nov 2014 11:37:33 +0000 (19:37 +0800)]
libcollection: generalize StrVector to AsSlice<Str>.
The impl for [T] also works as impl for slices in general.
By generalizing the impl of StrVector for Vec<Str> to that for
AsSlice<Str>, it becomes much more generic.
Once Iterable is implemented, we will prefer it to AsSlice.
But the with_capacity() part might become tricky.
bors [Sun, 23 Nov 2014 09:51:49 +0000 (09:51 +0000)]
auto merge of #19157 : aturon/rust/cow-doc, r=alexcrichton
This commit makes `Cow` more usable by allowing it to be applied to
unsized types (as was intended) and providing some basic `ToOwned`
implementations on slice types. It also corrects the documentation for
`Cow` to no longer mention `DerefMut`, and adds an example.
bors [Sun, 23 Nov 2014 05:46:52 +0000 (05:46 +0000)]
auto merge of #19152 : alexcrichton/rust/issue-17863, r=aturon
This commit is an implementation of [RFC 240][rfc] when applied to the standard
library. It primarily deprecates the entirety of `string::raw`, `vec::raw`,
`slice::raw`, and `str::raw` in favor of associated functions, methods, and
other free functions. The detailed renaming is:
Alex Crichton [Thu, 20 Nov 2014 18:11:15 +0000 (10:11 -0800)]
std: Align `raw` modules with unsafe conventions
This commit is an implementation of [RFC 240][rfc] when applied to the standard
library. It primarily deprecates the entirety of `string::raw`, `vec::raw`,
`slice::raw`, and `str::raw` in favor of associated functions, methods, and
other free functions. The detailed renaming is:
bors [Sat, 22 Nov 2014 06:31:43 +0000 (06:31 +0000)]
auto merge of #17513 : dradtke/rust/master, r=kballard
Looks like I made my previous PR a little too hastily. =)
This PR fixes a couple issues that I discovered with my previous revision:
1. Updated the errorformat to ignore "pointer lines" so that they don't show up in the output (with quickfix jumping, they're redundant and unnecessary).
2. Renamed a couple variables to be more in line with Cargo's terminology (`g:cargo_toml_name` should now be `g:cargo_manifest_name`).
3. Added support for errors reported with absolute paths (looks to be the case when compiling an executable instead of a library).
4. Most importantly, added support for errors reported while compiling a dependency. When building a Cargo package with local dependencies, if one of those dependencies failed to compile, the quickfix would be completely broken as it assumed that all errors were relative to the local manifest, or the closest Cargo.toml. With this update, it now pays attention to lines that end with `(file://<path>)`, and from then on adjusts all errors to be relative to `<path>`.
As a side note, that `<path>` output is somewhat broken on Windows. While `file:///home/damien/...` on *Nix is a valid URI, `file:///C:/Users/damien/...` on Windows is not, because `C:/` (or whatever the drive is) should take the place of the third slash which is *Nix's root, not be appended to it. I added a workaround for this in my script, but I figured I'd mention it to see if this is a bug in how Rust formats paths.
bors [Sat, 22 Nov 2014 04:06:45 +0000 (04:06 +0000)]
auto merge of #19122 : Kintaro/rust/remove_struct_variant, r=jakub-
The struct_variant is not gated anymore. This commit just removes it and the resulting warnings when compiling rust. Now compiles with the snapshot from 11/18 (as opposed to PR #19014)
bors [Sat, 22 Nov 2014 01:46:46 +0000 (01:46 +0000)]
auto merge of #19117 : jmesmon/rust/mk-cfg-suffix, r=cmr
Right now we'll end up globbing them into the accepted targets and (ever worse) they will override the make variables of real target files because we `include`d everything in that directory.
As a side effect, editors get a better hint on file types.
bors [Fri, 21 Nov 2014 23:16:48 +0000 (23:16 +0000)]
auto merge of #18603 : brson/rust/stdchar, r=aturon
* Deprecate the free functions in favor of methods, except the two ctors `from_u32` and `from_digit`, whose methods are deprecated.
* Mark the `Char` and `UnicodeChar` traits experimental until we decide for sure that we won't have some sort of inherent methods for primitives.
* The `UnicodeChar` methods related to numerics are now called e.g. `is_numeric` to match the 'numeric' unicode character class, and the `*_digit_radix` methods on `Char` now just called `*_digit`.
* `len_utf8_bytes` -> `len_utf8`
* Converted methods to take self by-value
* Converted `escape_default` and `escape_unicode` to iterators over chars.
* Renamed `is_XID_start`, `is_XID_continue` to `is_xid_start`, `is_xid_continue` to match conventions
This also converts `encode_utf8` and `encode_utf16` to return iterators. I suspect this is not the final form of these methods. Perf is worse (numbers in the commit). Many of the uses ended up being awkward, copying into a buffer then writing that buffer to a `Writer`. It might be more appropriate for these to return `Reader`s instead, but that type is defined in `std`.
Note: although I *did* add the `from_u32` ctor to the `Char` trait, I deprecated it again later, preferring the free ctors.
Aaron Turon [Fri, 21 Nov 2014 20:00:05 +0000 (12:00 -0800)]
libs: stabilize ascii module
This is an initial API stabilization pass for `std::ascii`. Aside from
some renaming to match conversion conventions, and deprecations in favor
of using iterators directly, almost nothing is changed here. However,
the static case conversion tables that were previously public are now private.
The stabilization of the (rather large!) set of extension traits is left
to a follow-up pass, because we hope to land some more general machinery
that will provide the same functionality without custom traits.
Brian Anderson [Mon, 13 Oct 2014 17:57:49 +0000 (10:57 -0700)]
core: Mark remaining Char methods unstable
The `Char` trait itself may go away in favor of primitive inherent
methods. Still some questions about whether the preconditions are
following the final error handling conventions.
Brian Anderson [Fri, 10 Oct 2014 21:55:11 +0000 (14:55 -0700)]
core: Add stability attributes to char::from_digit and from_u32
For now we are preferring free functions for primitive ctors,
so they are marked 'unstable' pending final decision. The
methods on `Char` are 'deprecated'.