bors [Sat, 3 Jan 2015 03:25:21 +0000 (03:25 +0000)]
auto merge of #20154 : P1start/rust/qualified-assoc-type-generics, r=nikomatsakis
This modifies `Parser::eat_lt` to always split up `<<`s, instead of doing so only when a lifetime name followed or the `force` parameter (now removed) was `true`. This is because `Foo<<TYPE` is now a valid start to a type, whereas previously only `Foo<<LIFETIME` was valid.
This is a [breaking-change]. Change code that looks like this:
bors [Sat, 3 Jan 2015 01:10:40 +0000 (01:10 +0000)]
auto merge of #19835 : pythonesque/rust/add-unordered-intrinsic, r=thestinger
This corresponds to the JMM memory model's non-volatile reads and writes to shared variables. It provides fairly weak guarantees, but prevents UB (specifically, you will never see a value that was not written _at some point_ to the provided location). It is not part of the C++ memory model and is only legal to provide to LLVM for loads and stores (not fences, atomicrmw, etc.).
Valid uses of this ordering are things like racy counters where you don't care about the operation actually being atomic, just want to avoid UB. It cannot be used for synchronization without additional memory barriers since unordered loads and stores may be reordered freely by the optimizer (this is the main way it differs from relaxed).
Because it is new to Rust and it provides so few guarantees, for now only the intrinsic is provided--this patch doesn't add it to any of the higher-level atomic wrappers.
Alex Crichton [Fri, 2 Jan 2015 17:22:44 +0000 (09:22 -0800)]
rollup merge of #20392: daramos/travis
Travis recently launched their new infrastructure on Amazon EC2 with improved resources. The only limitation is that they don't support sudo. http://blog.travis-ci.com/2014-12-17-faster-builds-with-container-based-infrastructure/
I couldn't find anywhere where the build system uses sudo so I don't think that limitation affects rust builds.
This change drops the current `make tidy` times [slightly](https://travis-ci.org/daramos/rust/builds)(travis-test branch).
Alex Crichton [Fri, 2 Jan 2015 17:22:22 +0000 (09:22 -0800)]
rollup merge of #20380: dcrewi/fix-make-install
There seems to be a problem introduced by 8b3c67690c4747b9fadfef407e6261524fb03f8a that causes "make install"
to fail when the build is not configured to skip doc building.
Niko Matsakis [Tue, 16 Dec 2014 02:11:09 +0000 (21:11 -0500)]
Refactor object-safety into its own (cached) module so that we can
check it more easily; also extend object safety to cover sized types
as well as static methods. This makes it sufficient so that we can
always ensure that `Foo : Foo` holds for any trait `Foo`.
Niko Matsakis [Sat, 20 Dec 2014 14:15:52 +0000 (09:15 -0500)]
Move the `upcast` routine into traits and use it for method selection; also
move get_method_index into traits and give it a better name (`get_vtable_index_of_object_method`).
Alex Crichton [Mon, 22 Dec 2014 17:04:23 +0000 (09:04 -0800)]
std: Stabilize the prelude module
This commit is an implementation of [RFC 503][rfc] which is a stabilization
story for the prelude. Most of the RFC was directly applied, removing reexports.
Some reexports are kept around, however:
* `range` remains until range syntax has landed to reduce churn.
* `Path` and `GenericPath` remain until path reform lands. This is done to
prevent many imports of `GenericPath` which will soon be removed.
* All `io` traits remain until I/O reform lands so imports can be rewritten all
at once to `std::io::prelude::*`.
This is a breaking change because many prelude reexports have been removed, and
the RFC can be consulted for the exact list of removed reexports, as well as to
find the locations of where to import them.
bors [Fri, 2 Jan 2015 15:51:25 +0000 (15:51 +0000)]
auto merge of #20356 : Gankro/rust/stab, r=aturon
This stabilizes most of libcollections, carefully avoiding sections of API which are being managed in other PRs. APIs which are not stable are marked explicitly unstable with a reason.
Niko Matsakis [Fri, 2 Jan 2015 02:41:44 +0000 (21:41 -0500)]
Fix an infinite loop in the stability check that was the result of
various bugs in `trait_id_of_impl`. The end result was that looking up
the "trait_id_of_impl" with a trait's def-id yielded the same trait
again, even though it ought to have yielded None.
Niko Matsakis [Thu, 1 Jan 2015 21:45:22 +0000 (16:45 -0500)]
Disable the JSON doctests because they don't pass the new coherence
rules and cannot be updated until the libraries are synced, nor can
they opt in to the old semantics.
Niko Matsakis [Fri, 26 Dec 2014 08:30:51 +0000 (03:30 -0500)]
Fix orphan checking (cc #19470). (This is not a complete fix of #19470 because of the backwards compatibility feature gate.)
This is a [breaking-change]. The new rules require that, for an impl of a trait defined
in some other crate, two conditions must hold:
1. Some type must be local.
2. Every type parameter must appear "under" some local type.
Here are some examples that are legal:
```rust
struct MyStruct<T> { ... }
// Here `T` appears "under' `MyStruct`.
impl<T> Clone for MyStruct<T> { }
// Here `T` appears "under' `MyStruct` as well. Note that it also appears
// elsewhere.
impl<T> Iterator<T> for MyStruct<T> { }
```
Here is an illegal example:
```rust
// Here `U` does not appear "under" `MyStruct` or any other local type.
// We call `U` "uncovered".
impl<T,U> Iterator<U> for MyStruct<T> { }
```
There are a couple of ways to rewrite this last example so that it is
legal:
1. In some cases, the uncovered type parameter (here, `U`) should be converted
into an associated type. This is however a non-local change that requires access
to the original trait. Also, associated types are not fully baked.
2. Add `U` as a type parameter of `MyStruct`:
```rust
struct MyStruct<T,U> { ... }
impl<T,U> Iterator<U> for MyStruct<T,U> { }
```
3. Create a newtype wrapper for `U`
```rust
impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { }
```
Because associated types are not fully baked, which in the case of the
`Hash` trait makes adhering to this rule impossible, you can
temporarily disable this rule in your crate by using
`#![feature(old_orphan_check)]`. Note that the `old_orphan_check`
feature will be removed before 1.0 is released.
bors [Fri, 2 Jan 2015 08:11:19 +0000 (08:11 +0000)]
auto merge of #20412 : nikomatsakis/rust/assoc-types, r=aturon
These changes fix various problems encountered getting japaric's `at-iter` branch to work. This branch converts the `Iterator` trait to use an associated type.
Alex Crichton [Fri, 2 Jan 2015 06:24:06 +0000 (22:24 -0800)]
std: Second pass stabilization for `boxed`
This commit performs a second pass over the `std::boxed` module, taking the
following actions:
* `boxed` is now stable
* `Box` is now stable
* `BoxAny` is removed in favor of a direct `impl Box<Any>`
* `Box::downcast` remains unstable while the name of the `downcast` family of
methods is determined.
This is a breaking change due to the removal of the `BoxAny` trait (note that
the `downcast` method still exists), and existing consumers of `BoxAny` simply
need to remove the import in their modules.
Alex Crichton [Fri, 12 Dec 2014 18:59:41 +0000 (10:59 -0800)]
std: Enforce Unicode in fmt::Writer
This commit is an implementation of [RFC 526][rfc] which is a change to alter
the definition of the old `fmt::FormatWriter`. The new trait, renamed to
`Writer`, now only exposes one method `write_str` in order to guarantee that all
implementations of the formatting traits can only produce valid Unicode.
One of the primary improvements of this patch is the performance of the
`.to_string()` method by avoiding an almost-always redundant UTF-8 check. This
is a breaking change due to the renaming of the trait as well as the loss of the
`write` method, but migration paths should be relatively easy:
* All usage of `write` should move to `write_str`. If truly binary data was
being written in an implementation of `Show`, then it will need to use a
different trait or an altogether different code path.
* All usage of `write!` should continue to work as-is with no modifications.
* All usage of `Show` where implementations just delegate to another should
continue to work as-is.
Alex Crichton [Mon, 29 Dec 2014 23:03:01 +0000 (15:03 -0800)]
std: Second pass stabilization of sync
This pass performs a second pass of stabilization through the `std::sync`
module, avoiding modules/types that are being handled in other PRs (e.g.
mutexes, rwlocks, condvars, and channels).
* `sync::SemaphoreGuard`
* `sync::Semaphore::access` - it's unclear how this relates to the poisoning
story of mutexes.
* `sync::TaskPool` - the semantics of a failing task and whether a thread is
re-attached to a thread pool are somewhat unclear, and the
utility of this type in `sync` is question with respect to
the jobs of other primitives. This type will likely become
stable or move out of the standard library over time.
* `sync::Future` - futures as-is have yet to be deeply re-evaluated with the
recent core changes to Rust's synchronization story, and will
likely become stable in the future but are unstable until
that time comes.
bors [Thu, 1 Jan 2015 15:51:08 +0000 (15:51 +0000)]
auto merge of #20190 : cmr/rust/gate-macro-args, r=alexcrichton
Uses the same approach as https://github.com/rust-lang/rust/pull/17286 (and
subsequent changes making it more correct), where the visitor will skip any
pieces of the AST that are from "foreign code", where the spans don't line up,
indicating that that piece of code is due to a macro expansion.
If this breaks your code, read the error message to determine which feature
gate you should add to your crate.
Corey Richardson [Wed, 24 Dec 2014 05:44:13 +0000 (00:44 -0500)]
Feature gate macro arguments
Uses the same approach as https://github.com/rust-lang/rust/pull/17286 (and
subsequent changes making it more correct), where the visitor will skip any
pieces of the AST that are from "foreign code", where the spans don't line up,
indicating that that piece of code is due to a macro expansion.
If this breaks your code, read the error message to determine which feature
gate you should add to your crate, and bask in the knowledge that your code
won't mysteriously break should you try to use the 1.0 release.
bors [Thu, 1 Jan 2015 06:36:24 +0000 (06:36 +0000)]
auto merge of #19388 : nick29581/rust/rc-show, r=alexcrichto
r? @huonw or @alexcrichton
Apparently, we have previously rejected an RFC like this. However, since then we removed `{:?}` and so without this debugging gets really difficult as soon as there is a RefCell anywhere, so I believe there is more benefit to adding these impls than there was before. By using "try_borrow" we can avoid panicing in `Show` (I think).
@ huon in response to a comment in #19254: I noticed that `drop()` checks for the ptr being null, so I checked here too. Now I am checking for both, if you're confident I can change to only checking `strong()`.
bors [Thu, 1 Jan 2015 04:01:02 +0000 (04:01 +0000)]
auto merge of #20363 : japaric/rust/moar-uc, r=nmatsakis
The the last argument of the `ItemDecorator::expand` method has changed to `Box<FnMut>`. Syntax extensions will break.
[breaking-change]
---
This PR removes pretty much all the remaining uses of boxed closures from the libraries. There are still boxed closures under the `test` directory, but I think those should be removed or replaced with unboxed closures at the same time we remove boxed closures from the language.
In a few places I had to do some contortions (see the first commit for an example) to work around issue #19596. I have marked those workarounds with FIXMEs. In the future when `&mut F where F: FnMut` implements the `FnMut` trait, we should be able to remove those workarounds. I've take care to avoid placing the workaround functions in the public API.
Since `let f = || {}` always gets type checked as a boxed closure, I have explictly annotated those closures (with e.g. `|&:| {}`) to force the compiler to type check them as unboxed closures.
Instead of removing the type aliases (like `GetCrateDataCb`), I could have replaced them with newtypes. But this seemed like overcomplicating things for little to no gain.
I think we should be able to remove the boxed closures from the languge after this PR lands. (I'm being optimistic here)
projects / rust.git / log