77 Commits

Author SHA1 Message Date
Steven Fackler
348cc9418a Remove special casing for some meta attributes
Descriptions and licenses are handled by Cargo now, so there's no reason
to keep these attributes around.
2014-11-26 11:44:45 -08:00
Subhash Bhushan
bc9de771d5 Rename remaining Failures to Panic 2014-11-20 23:45:42 +05:30
Steven Fackler
3dcd215740 Switch to purely namespaced enums
This breaks code that referred to variant names in the same namespace as
their enum. Reexport the variants in the old location or alter code to
refer to the new locations:

```
pub enum Foo {
    A,
    B
}

fn main() {
    let a = A;
}
```
=>
```
pub use self::Foo::{A, B};

pub enum Foo {
    A,
    B
}

fn main() {
    let a = A;
}
```
or
```
pub enum Foo {
    A,
    B
}

fn main() {
    let a = Foo::A;
}
```

[breaking-change]
2014-11-17 07:35:51 -08:00
Nick Cameron
ca08540a00 Fix fallout from coercion removal 2014-11-17 22:41:33 +13:00
Brendan Zabarauskas
e965ba85ca Remove lots of numeric traits from the preludes
Num, NumCast, Unsigned, Float, Primitive and Int have been removed.
2014-11-13 03:46:03 +11:00
Dan Burkert
05f6bdaefc Tuple deserialization should not fail 2014-11-01 10:54:34 -07:00
Dan Burkert
ca6b082c05 libserialize: tuple-arity should be provided to Decoder::read_tuple
Currently `Decoder` implementations are not provided the tuple arity as
a parameter to `read_tuple`. This forces all encoder/decoder combos to
serialize the arity along with the elements. Tuple-arity is always known
statically at the decode site, because it is part of the type of the
tuple, so it could instead be provided as an argument to `read_tuple`,
as it is to `read_struct`.

The upside to this is that serialized tuples could become smaller in
encoder/decoder implementations which choose not to serialize type
(arity) information. For example, @TyOverby's
[binary-encode](https://github.com/TyOverby/binary-encode) format is
currently forced to serialize the tuple-arity along with every tuple,
despite the information being statically known at the decode site.

A downside to this change is that the tuple-arity of serialized tuples
can no longer be automatically checked during deserialization. However,
for formats which do serialize the tuple-arity, either explicitly (rbml)
or implicitly (json), this check can be added to the `read_tuple` method.

The signature of `Deserialize::read_tuple` and
`Deserialize::read_tuple_struct` are changed, and thus binary
backwards-compatibility is broken. This change does *not* force
serialization formats to change, and thus does not break decoding values
serialized prior to this change.

[breaking-change]
2014-11-01 10:54:34 -07:00
Alex Crichton
00975e041d rollup merge of #18398 : aturon/lint-conventions-2
Conflicts:
	src/libcollections/slice.rs
	src/libcore/failure.rs
	src/libsyntax/parse/token.rs
	src/test/debuginfo/basic-types-mut-globals.rs
	src/test/debuginfo/simple-struct.rs
	src/test/debuginfo/trait-pointers.rs
2014-10-30 17:37:22 -07:00
Steve Klabnik
7828c3dd28 Rename fail! to panic!
https://github.com/rust-lang/rfcs/pull/221

The current terminology of "task failure" often causes problems when
writing or speaking about code. You often want to talk about the
possibility of an operation that returns a Result "failing", but cannot
because of the ambiguity with task failure. Instead, you have to speak
of "the failing case" or "when the operation does not succeed" or other
circumlocutions.

Likewise, we use a "Failure" header in rustdoc to describe when
operations may fail the task, but it would often be helpful to separate
out a section describing the "Err-producing" case.

We have been steadily moving away from task failure and toward Result as
an error-handling mechanism, so we should optimize our terminology
accordingly: Result-producing functions should be easy to describe.

To update your code, rename any call to `fail!` to `panic!` instead.
Assuming you have not created your own macro named `panic!`, this
will work on UNIX based systems:

    grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g'

You can of course also do this by hand.

[breaking-change]
2014-10-29 11:43:07 -04:00
Aaron Turon
e0ad0fcb95 Update code with new lint names 2014-10-28 08:54:21 -07:00
Brian Anderson
5c92a8e054 Use the same html_root_url for all docs 2014-10-09 10:50:13 -07:00
Brian Anderson
6beddcfd83 Revert "Update html_root_url for 0.12.0 release"
This reverts commit 2288f332301b9e22db2890df256322650a7f3445.
2014-10-09 10:34:34 -07:00
Brian Anderson
2288f33230 Update html_root_url for 0.12.0 release 2014-10-07 11:18:50 -07:00
Nick Cameron
2d3823441f Put slicing syntax behind a feature gate.
[breaking-change]

If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
2014-10-07 15:49:53 +13:00
Nick Cameron
59976942ea Use slice syntax instead of slice_to, etc. 2014-10-07 15:49:53 +13:00
Aaron Turon
d2ea0315e0 Revert "Use slice syntax instead of slice_to, etc."
This reverts commit 40b9f5ded50ac4ce8c9323921ec556ad611af6b7.
2014-10-02 11:48:07 -07:00
Aaron Turon
7bf56df4c8 Revert "Put slicing syntax behind a feature gate."
This reverts commit 95cfc35607ccf5f02f02de56a35a9ef50fa23a82.
2014-10-02 11:47:51 -07:00
Nick Cameron
95cfc35607 Put slicing syntax behind a feature gate.
[breaking-change]

If you are using slicing syntax you will need to add #![feature(slicing_syntax)] to your crate.
2014-10-02 13:23:36 +13:00
Nick Cameron
40b9f5ded5 Use slice syntax instead of slice_to, etc. 2014-10-02 13:19:45 +13:00
Jonas Hietala
947a1b923b Remove some test warnings. 2014-09-09 11:32:58 +02:00
bors
f297366593 auto merge of #16859 : alexcrichton/rust/snapshots, r=huonw 2014-08-30 19:51:25 +00:00
Alex Crichton
d15d559739 Register new snapshots 2014-08-29 14:33:08 -07:00
P1start
de7abd8824 Unify non-snake-case lints and non-uppercase statics lints
This unifies the `non_snake_case_functions` and `uppercase_variables` lints
into one lint, `non_snake_case`. It also now checks for non-snake-case modules.
This also extends the non-camel-case types lint to check type parameters, and
merges the `non_uppercase_pattern_statics` lint into the
`non_uppercase_statics` lint.

Because the `uppercase_variables` lint is now part of the `non_snake_case`
lint, all non-snake-case variables that start with lowercase characters (such
as `fooBar`) will now trigger the `non_snake_case` lint.

New code should be updated to use the new `non_snake_case` lint instead of the
previous `non_snake_case_functions` and `uppercase_variables` lints. All use of
the `non_uppercase_pattern_statics` should be replaced with the
`non_uppercase_statics` lint. Any code that previously contained non-snake-case
module or variable names should be updated to use snake case names or disable
the `non_snake_case` lint. Any code with non-camel-case type parameters should
be changed to use camel case or disable the `non_camel_case_types` lint.

[breaking-change]
2014-08-30 09:10:05 +12:00
Niko Matsakis
1b487a8906 Implement generalized object and type parameter bounds (Fixes #16462) 2014-08-27 21:46:52 -04:00
Andrew Poelstra
5bd8edc112 libserialize: add error() to Decoder
A quick and dirty fix for #15036 until we get serious decoder reform.

Right now it is impossible for a Decodable to signal a decode error,
for example if it has only finitely many allowed values, is a string
which must be encoded a certain way, needs a valid checksum, etc. For
example in the libuuid implementation of Decodable an Option is
unwrapped, meaning that a decode of a malformed UUID will cause the
task to fail.

Since this adds a method to the `Decoder` trait, all users will need
to update their implementations to add it. The strategy used for the
current implementations for JSON and EBML is to add a new entry to
the error enum `ApplicationError(String)` which stores the string
provided to `.error()`.

[breaking-change]
2014-07-31 21:41:19 -07:00
Erick Tryzelaar
fd9ad77bd2 Move SeekableMemWriter into librbml 2014-07-31 07:30:50 -07:00
Erick Tryzelaar
e1dcbefe52 remove serialize::ebml, add librbml
Our implementation of ebml has diverged from the standard in order
to better serve the needs of the compiler, so it doesn't make much
sense to call what we have ebml anyore. Furthermore, our implementation
is pretty crufty, and should eventually be rewritten into a format
that better suits the needs of the compiler. This patch factors out
serialize::ebml into librbml, otherwise known as the Really Bad
Markup Language. This is a stopgap library that shouldn't be used
by end users, and will eventually be replaced by something better.

[breaking-change]
2014-07-31 07:30:49 -07:00