1724 Commits

Author SHA1 Message Date
bors
3e6b29f8ad auto merge of #20136 : eddyb/rust/format-args, r=alexcrichton
We have the technology: no longer do you need to write closures to use `format_args!`.
This is a `[breaking-change]`, as it forces you to clean up old hacks - if you had code like this:
```rust
format_args!(fmt::format, "{} {} {}", a, b, c)
format_args!(|args| { w.write_fmt(args) }, "{} {} {}", x, y, z)
```
change it to this: 
```rust
fmt::format(format_args!("{} {} {}", a, b, c))
w.write_fmt(format_args!("{} {} {}", x, y, z))
```
To allow them to be called with `format_args!(...)` directly, several functions were modified to
take `fmt::Arguments` by value instead of by reference. Also, `fmt::Arguments` derives `Copy`
now in order to preserve all usecases that were previously possible.
2014-12-28 03:11:48 +00:00
Eduard Burtescu
fc3f22bf25 syntax: change format_args! to produce fmt::Arguments instead of calling a function with them. 2014-12-27 23:55:14 +02:00
Eduard Burtescu
3961adcaf0 syntax: use std::string::String unqualified in format. 2014-12-27 23:55:14 +02:00
Eduard Burtescu
68a7f1b5e3 syntax: turn the match-call generated by format_args inside-out. 2014-12-27 23:55:14 +02:00
Eduard Burtescu
17b3c1107a syntax: format: put static arrays in their own blocks to avoid needing a wrapper block. 2014-12-27 23:55:14 +02:00
Eduard Burtescu
22376be754 syntax: format: remove unused method_statics field. 2014-12-27 23:55:14 +02:00
bors
070ab63807 auto merge of #19916 : SimonSapin/rust/ascii-reform, r=sfackler
Implements [RFC 486](https://github.com/rust-lang/rfcs/pull/486). Fixes #19908.

* Rename `to_ascii_{lower,upper}` to `to_ascii_{lower,upper}case`, per #14401
* Remove the `Ascii` type and associated traits: `AsciiCast`, `OwnedAsciiCast`, `AsciiStr`, `IntoBytes`, and `IntoString`.
* As a replacement, add `.is_ascii()` to `AsciiExt`, and implement `AsciiExt` for `u8` and `char`.

[breaking-change]
2014-12-27 21:51:43 +00:00
Flavio Percoco
607f60712c Keep track of the whole error chain 2014-12-26 17:26:33 +01:00
Simon Sapin
3a6ccdc263 Remove Ascii, AsciiCast, OwnedAsciiCast, AsciiStr, IntoBytes, IntoString.
As a replacement, add is_ascii() to AsciiExt, and implement AsciiExt for u8 and char.

[breaking-change]
2014-12-25 12:19:37 +01:00
Chris Wong
85c1a4b1ba Rename include_bin! to include_bytes!
According to [RFC 344][], methods that return `&[u8]` should have names
ending in `bytes`. Though `include_bin!` is a macro not a method, it
seems reasonable to follow the convention anyway.

We keep the old name around for now, but trigger a deprecation warning
when it is used.

[RFC 344]: https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md

[breaking-change]
2014-12-23 22:06:32 +13:00
Alex Crichton
de11710d80 rollup merge of #19891: nikomatsakis/unique-fn-types-3
Conflicts:
	src/libcore/str.rs
	src/librustc_trans/trans/closure.rs
	src/librustc_typeck/collect.rs
	src/libstd/path/posix.rs
	src/libstd/path/windows.rs
2014-12-22 12:51:23 -08:00
Alex Crichton
459f3b2cfa rollup merge of #20056: MrFloya/iter_rename
Conflicts:
	src/libcollections/bit.rs
	src/libcore/str.rs
2014-12-22 12:49:57 -08:00
Alex Crichton
b04bc5cc49 rollup merge of #20033: alexcrichton/deprecate-serialise
This commit completes the deprecation story for the in-tree serialization
library. The compiler will now emit a warning whenever it encounters
`deriving(Encodable)` or `deriving(Decodable)`, and the library itself is now
marked `#[unstable]` for when feature staging is enabled.

All users of serialization can migrate to the `rustc-serialize` crate on
crates.io which provides the exact same interface as the libserialize library
in-tree. The new deriving modes are named `RustcEncodable` and `RustcDecodable`
and require `extern crate "rustc-serialize" as rustc_serialize` at the crate
root in order to expand correctly.

To migrate all crates, add the following to your `Cargo.toml`:

    [dependencies]
    rustc-serialize = "0.1.1"

And then add the following to your crate root:

    extern crate "rustc-serialize" as rustc_serialize;

Finally, rename `Encodable` and `Decodable` deriving modes to `RustcEncodable`
and `RustcDecodable`.

[breaking-change]
2014-12-22 12:46:31 -08:00
Niko Matsakis
7f6177e646 Fix fallout from changes. In cases where stage0 compiler is needed, we
cannot use an `as` expression to coerce, so I used a one-off function
instead (this is a no-op in stage0, but in stage1+ it triggers
coercion from the fn pointer to the fn item type).
2014-12-22 12:27:07 -05:00
Florian Wilkens
f8cfd2480b Renaming of the Iter types as in RFC #344
libcore: slice::Items -> slice::Iter, slice::MutItems -> slice::IterMut
libcollections: *::Items -> *::Iter, *::MoveItems -> *::IntoIter, *::MutItems -> *::IterMut

This is of course a [breaking-change].
2014-12-22 12:58:55 +01:00
Alex Crichton
a76a802768 serialize: Fully deprecate the library
This commit completes the deprecation story for the in-tree serialization
library. The compiler will now emit a warning whenever it encounters
`deriving(Encodable)` or `deriving(Decodable)`, and the library itself is now
marked `#[unstable]` for when feature staging is enabled.

All users of serialization can migrate to the `rustc-serialize` crate on
crates.io which provides the exact same interface as the libserialize library
in-tree. The new deriving modes are named `RustcEncodable` and `RustcDecodable`
and require `extern crate "rustc-serialize" as rustc_serialize` at the crate
root in order to expand correctly.

To migrate all crates, add the following to your `Cargo.toml`:

    [dependencies]
    rustc-serialize = "0.1.1"

And then add the following to your crate root:

    extern crate "rustc-serialize" as rustc_serialize;

Finally, rename `Encodable` and `Decodable` deriving modes to `RustcEncodable`
and `RustcDecodable`.

[breaking-change]
2014-12-22 00:14:56 -08:00
Alex Crichton
082bfde412 Fallout of std::str stabilization 2014-12-21 23:31:42 -08:00
Alex Crichton
dbeef0edb2 rollup merge of #19972: alexcrichton/snapshots
Conflicts:
	src/libcollections/string.rs
	src/libcollections/vec.rs
	src/snapshots.txt
2014-12-21 09:28:07 -08:00
Alex Crichton
40e1f7c6ba rollup merge of #20080: seanmonstar/new-show-syntax
First step of #20013. This will allow (after a snapshot) to change all the debug strings from `{}` to `{:?}`.

r? @alexcrichton
2014-12-21 09:27:37 -08:00
Alex Crichton
e1d09766ad rollup merge of #20059: nick29581/self-impl
r? @sfackler

closes #20000
2014-12-21 09:27:35 -08:00
Alex Crichton
eb47e1e446 rollup merge of #20039: barosl/if-let-friendly-error
Fixes #19991.
2014-12-21 09:27:34 -08:00
Corey Farwell
98af642f5c Remove a ton of public reexports
Remove most of the public reexports mentioned in #19253

These are all leftovers from the enum namespacing transition

In particular:

* src/libstd/num/strconv.rs
 * ExponentFormat
 * SignificantDigits
 * SignFormat
* src/libstd/path/windows.rs
 * PathPrefix
* src/libstd/sys/windows/timer.rs
 * Req
* src/libcollections/str.rs
 * MaybeOwned
* src/libstd/collections/hash/map.rs
 * Entry
* src/libstd/collections/hash/table.rs
 * BucketState
* src/libstd/dynamic_lib.rs
 * Rtld
* src/libstd/io/net/ip.rs
 * IpAddr
* src/libstd/os.rs
 * MemoryMapKind
 * MapOption
 * MapError
* src/libstd/sys/common/net.rs
 * SocketStatus
 * InAddr
* src/libstd/sys/unix/timer.rs
 * Req

[breaking-change]
2014-12-21 09:26:41 -08:00
Jared Roesch
d87b308b67 Add support for multiple region bounds in where clauses 2014-12-20 03:54:39 -08:00
Jared Roesch
e0cac488ac Add parser support for generalized where clauses
Implement support in the parser for generalized where clauses,
as well as the conversion of ast::WherePredicates to
ty::Predicate in `collect.rs`.
2014-12-20 02:48:17 -08:00
Sean McArthur
84b8f318a5 add {:?} fmt syntax 2014-12-20 00:32:07 -08:00
Nick Cameron
31f5ab3f0c Allow Self in impls. 2014-12-20 21:11:36 +13:00
Barosl Lee
314ed2df09 Drop the Match prefix from the MatchSource variants 2014-12-20 09:17:14 +09:00
Barosl Lee
7023bea22c Print a friendly error for the if-let construct without an else block
Fixes #19991.
2014-12-20 09:17:14 +09:00
bors
cbe9fb45bc auto merge of #19463 : kali/rust/master, r=alexcrichton
parse_ty() no longer takes a boolean parameter. quote_ty! implementation has not yet been modified accordingly. 

As a matter of fact, quote_ty! was not covered by tests. One test (called qquotes) references it, but it has been ignored for nearly one year and now need heavy refactoring.

quote_token.rs seemed like a good place to test quote_ty!, many other quote_*! macros were asserted there.
2014-12-19 20:22:17 +00:00
Alex Crichton
84086c464f Register new snapshots
This does not yet start the movement to rustc-serialize. That detail is left to
a future PR.
2014-12-19 08:58:10 -08:00
Jorge Aparicio
86f8c127dd libsyntax: use #[deriving(Copy)] 2014-12-19 10:51:00 -05:00
Mathieu Poumeyrol
8920181052 ack parser.parse_ty change in quote_ty! (+ test) 2014-12-19 15:25:02 +01:00
Patrick Walton
ddb2466f6a librustc: Always parse macro!()/macro![] as expressions if not
followed by a semicolon.

This allows code like `vec![1i, 2, 3].len();` to work.

This breaks code that uses macros as statements without putting
semicolons after them, such as:

    fn main() {
        ...
        assert!(a == b)
        assert!(c == d)
        println(...);
    }

It also breaks code that uses macros as items without semicolons:

    local_data_key!(foo)

    fn main() {
        println("hello world")
    }

Add semicolons to fix this code. Those two examples can be fixed as
follows:

    fn main() {
        ...
        assert!(a == b);
        assert!(c == d);
        println(...);
    }

    local_data_key!(foo);

    fn main() {
        println("hello world")
    }

RFC #378.

Closes #18635.

[breaking-change]
2014-12-18 12:09:07 -05:00
Alex Crichton
5c98952409 Test fixes and rebase conflicts 2014-12-17 11:50:32 -08:00
Alex Crichton
bdb1146181 rollup merge of #19831: luqmana/deriving-where
Fixes #19358.
2014-12-17 11:50:25 -08:00
Alex Crichton
fc1b4379eb rollup merge of #19755: alexcrichton/rust-serialize
The primary focus of Rust's stability story at 1.0 is the standard library.
All other libraries distributed with the Rust compiler are planned to
be #[unstable] and therfore only accessible on the nightly channel of Rust. One
of the more widely used libraries today is libserialize, Rust's current solution
for encoding and decoding types.

The current libserialize library, however, has a number of drawbacks:

* The API is not ready to be stabilize as-is and we will likely not have enough
  resources to stabilize the API for 1.0.
* The library is not necessarily the speediest implementations with alternatives
  being developed out-of-tree (e.g. serde from erickt).
* It is not clear how the API of Encodable/Decodable can evolve over time while
  maintaining backwards compatibility.

One of the major pros to the current libserialize, however, is
`deriving(Encodable, Decodable)` as short-hands for enabling serializing and
deserializing a type. This is unambiguously useful functionality, so we cannot
simply deprecate the in-tree libserialize in favor of an external crates.io
implementation.

For these reasons, this commit starts off a stability story for libserialize by
following these steps:

1. The deriving(Encodable, Decodable) modes will be deprecated in favor of a
   renamed deriving(RustcEncodable, RustcDecodable).
2. The in-tree libserialize will be deprecated in favor of an external
   rustc-serialize crate shipped on crates.io. The contents of the crate will be
   the same for now (but they can evolve separately).
3. At 1.0 serialization will be performed through
   deriving(RustcEncodable, RustcDecodable) and the rustc-serialize crate. The
   expansions for each deriving mode will change from `::serialize::foo` to
   `::rustc_serialize::foo`.

This story will require that the compiler freezes its implementation of
`RustcEncodable` deriving for all of time, but this should be a fairly minimal
maintenance burden. Otherwise the crate in crates.io must always maintain the
exact definition of its traits, but the implementation of json, for example, can
continue to evolve in the semver-sense.

The major goal for this stabilization effort is to pave the road for a new
official serialization crate which can replace the current one, solving many of
its downsides in the process. We are not assuming that this will exist for 1.0,
hence the above measures. Some possibilities for replacing libserialize include:

* If plugins have a stable API, then any crate can provide a custom `deriving`
  mode (will require some compiler work). This means that any new serialization
  crate can provide its own `deriving` with its own backing
  implementation, entirely obsoleting the current libserialize and fully
  replacing it.

* Erick is exploring the possibility of code generation via preprocessing Rust
  source files in the near term until plugins are stable. This strategy would
  provide the same ergonomic benefit that `deriving` does today in theory.

So, in summary, the current libserialize crate is being deprecated in favor of
the crates.io-based rustc-serialize crate where the `deriving` modes are
appropriately renamed. This opens up space for a later implementation of
serialization in a more official capacity while allowing alternative
implementations to be explored in the meantime.

Concretely speaking, this change adds support for the `RustcEncodable` and
`RustcDecodable` deriving modes. After a snapshot is made warnings will be
turned on for usage of `Encodable` and `Decodable` as well as deprecating the
in-tree libserialize crate to encurage users to use rustc-serialize instead.
2014-12-17 11:50:23 -08:00
bors
41f5907fa6 auto merge of #19777 : nikomatsakis/rust/warn-on-shadowing, r=acrichto
per rfc 459
cc https://github.com/rust-lang/rust/issues/19390

One question is: should we start by warning, and only switch to hard error later? I think we discussed something like this in the meeting. 

r? @alexcrichton
2014-12-16 08:42:40 +00:00
bors
0669a432a2 auto merge of #19448 : japaric/rust/binops-by-value, r=nikomatsakis
- The following operator traits now take their arguments by value: `Add`, `Sub`, `Mul`, `Div`, `Rem`, `BitAnd`, `BitOr`, `BitXor`, `Shl`, `Shr`. This breaks all existing implementations of these traits.

- The binary operation `a OP b` now "desugars" to `OpTrait::op_method(a, b)` and consumes both arguments.

- `String` and `Vec` addition have been changed to reuse the LHS owned value, and to avoid internal cloning. Only the following asymmetric operations are available: `String + &str` and `Vec<T> + &[T]`, which are now a short-hand for the "append" operation.

[breaking-change]

---

This passes `make check` locally. I haven't touch the unary operators in this PR, but converting them to by value should be very similar to this PR. I can work on them after this gets the thumbs up.

@nikomatsakis r? the compiler changes
@aturon r? the library changes. I think the only controversial bit is the semantic change of the `Vec`/`String` `Add` implementation.
cc #19148
2014-12-15 22:11:44 +00:00
Niko Matsakis
1718cd6ee0 Remove all shadowed lifetimes. 2014-12-15 10:23:48 -05:00
Brian Anderson
f0bf34de9f rollup merge of #19812: frewsxcv/expansion-include-enum
In preparation for [removing the `std::cmp::Ordering` reexport](https://github.com/rust-lang/rust/issues/19253), this needs to be done to prevent errors like:

```
note: in expansion of #[deriving]
note: expansion site
error: unresolved name `std::cmp::Equal`
#[deriving(Clone, PartialEq, PartialOrd, Eq, Ord, Show)]
                                             ^~~
```
2014-12-15 06:45:36 -08:00
bors
ef0bc464af auto merge of #19778 : aochagavia/rust/ice, r=alexcrichton
Fixes #19734
2014-12-15 11:17:44 +00:00
Niko Matsakis
22f777ba2e Parse unsafe impl but don't do anything particularly interesting with the results. 2014-12-14 11:11:55 -05:00
Niko Matsakis
092d04a40a Rename FnStyle trait to Unsafety. 2014-12-14 11:11:55 -05:00
Niko Matsakis
d258d68db6 Remove proc types/expressions from the parser, compiler, and
language. Recommend `move||` instead.
2014-12-14 04:21:56 -05:00
Luqman Aden
ac7dc03a52 libsyntax: Make deriving also respect where bounds. 2014-12-14 01:13:23 -05:00
Alex Crichton
7d1fa4ebea rustc: Start the deprecation of libserialize
The primary focus of Rust's stability story at 1.0 is the standard library.
All other libraries distributed with the Rust compiler are planned to
be #[unstable] and therfore only accessible on the nightly channel of Rust. One
of the more widely used libraries today is libserialize, Rust's current solution
for encoding and decoding types.

The current libserialize library, however, has a number of drawbacks:

* The API is not ready to be stabilize as-is and we will likely not have enough
  resources to stabilize the API for 1.0.
* The library is not necessarily the speediest implementations with alternatives
  being developed out-of-tree (e.g. serde from erickt).
* It is not clear how the API of Encodable/Decodable can evolve over time while
  maintaining backwards compatibility.

One of the major pros to the current libserialize, however, is
`deriving(Encodable, Decodable)` as short-hands for enabling serializing and
deserializing a type. This is unambiguously useful functionality, so we cannot
simply deprecate the in-tree libserialize in favor of an external crates.io
implementation.

For these reasons, this commit starts off a stability story for libserialize by
following these steps:

1. The deriving(Encodable, Decodable) modes will be deprecated in favor of a
   renamed deriving(RustcEncodable, RustcDecodable).
2. The in-tree libserialize will be deprecated in favor of an external
   rustc-serialize crate shipped on crates.io. The contents of the crate will be
   the same for now (but they can evolve separately).
3. At 1.0 serialization will be performed through
   deriving(RustcEncodable, RustcDecodable) and the rustc-serialize crate. The
   expansions for each deriving mode will change from `::serialize::foo` to
   `::rustc_serialize::foo`.

This story will require that the compiler freezes its implementation of
`RustcEncodable` deriving for all of time, but this should be a fairly minimal
maintenance burden. Otherwise the crate in crates.io must always maintain the
exact definition of its traits, but the implementation of json, for example, can
continue to evolve in the semver-sense.

The major goal for this stabilization effort is to pave the road for a new
official serialization crate which can replace the current one, solving many of
its downsides in the process. We are not assuming that this will exist for 1.0,
hence the above measures. Some possibilities for replacing libserialize include:

* If plugins have a stable API, then any crate can provide a custom `deriving`
  mode (will require some compiler work). This means that any new serialization
  crate can provide its own `deriving` with its own backing
  implementation, entirely obsoleting the current libserialize and fully
  replacing it.

* Erick is exploring the possibility of code generation via preprocessing Rust
  source files in the near term until plugins are stable. This strategy would
  provide the same ergonomic benefit that `deriving` does today in theory.

So, in summary, the current libserialize crate is being deprecated in favor of
the crates.io-based rustc-serialize crate where the `deriving` modes are
appropriately renamed. This opens up space for a later implementation of
serialization in a more official capacity while allowing alternative
implementations to be explored in the meantime.

Concretely speaking, this change adds support for the `RustcEncodable` and
`RustcDecodable` deriving modes. After a snapshot is made warnings will be
turned on for usage of `Encodable` and `Decodable` as well as deprecating the
in-tree libserialize crate to encurage users to use rustc-serialize instead.
2014-12-13 18:36:09 -08:00
Jorge Aparicio
c4fa2a37ae libsyntax: convert LockstepIterSize binops to by value 2014-12-13 20:15:39 -05:00
Jorge Aparicio
0dac05dd62 libsyntax: use unboxed closures 2014-12-13 17:03:47 -05:00
Jorge Aparicio
5e7469cfe1 libsyntax: fix fallout 2014-12-13 17:03:44 -05:00
Corey Farwell
3fc6dc95b4 Expansion should explicitly include enum
In preparation for removing the std::cmp::Ordering reexport, this needs
to be done to prevent errors like:

```
note: in expansion of #[deriving]
note: expansion site
error: unresolved name `std::cmp::Equal`
\#[deriving(Clone, PartialEq, PartialOrd, Eq, Ord, Show)]
                                              ^~~
```
2014-12-13 09:57:46 -05:00