Commit Graph

35561 Commits

Author SHA1 Message Date
Tobias Bucher
67ae3a49e4 Clean up libcollections::VecMap
- Introduce a named type for the return type of `VecMap::move_iter`
- Rename all type parameters to `V` for "Value".
- Remove unnecessary call to an `Option::unwrap`, use pattern matching instead.
- Remove incorrect `Hash` implementation which took the `VecMap`'s capacity
  into account.

This is a [breaking-change], however whoever used the `Hash` implementation
relied on an incorrect implementation.
2014-12-09 18:20:20 +01:00
jbranchaud
de3fcee2dc Add a doctest for the std::string::as_string method.
Change Example to Examples.

Add a doctest that better demonstrates the utility of as_string.

Update the doctest example to use String instead of &String.
2014-12-09 11:11:50 -06:00
Maxime Quandalle
c93d47d395 Delete the outdated source layout README 2014-12-09 16:53:22 +01:00
Arcterus
a119ad83c7 serialize: base64: remove some .as_bytes() from the tests 2014-12-09 07:40:21 -08:00
Arcterus
a943a7a4e5 serialize: base64: improve newline handling speed 2014-12-09 07:40:21 -08:00
Arcterus
553ab271a3 serialize: base64: allow LF in addition to CRLF and optimize slightly
It is useful to have configurable newlines in base64 as the standard
leaves that for the implementation to decide.  GNU `base64` apparently
uses LF, which meant in `uutils` we had to manually convert the CRLF to
LF.  This made the program very slow for large inputs.

[breaking-change]
2014-12-09 07:40:21 -08:00
bors
ef4982f0f8 auto merge of #19466 : nikomatsakis/rust/recursion-limit, r=eddyb
This is particularly important for deeply nested types, which generate deeply nested impls. This is a fix for #19318. It's possible we could also improve this particular case not to increment the recursion count, but it's worth being able to adjust the recursion limit anyhow.

cc @jdm 
r? @pcwalton
2014-12-09 14:02:45 +00:00
bors
cafe296677 auto merge of #19249 : barosl/rust/json-type-safety, r=alexcrichton
This pull request tries to improve type safety of `serialize::json::Encoder`.

Looking at #18319, I decided to test some JSON implementations in other languages. The results are as follows:

* Encoding to JSON

| Language | 111111111111111111 | 1.0 |
| --- | --- | --- |
| JavaScript™ | "111111111111111100" | "1" |
| Python | "111111111111111111" | **"1.0"** |
| Go | "111111111111111111" | "1" |
| Haskell | "111111111111111111" | "1" |
| Rust | **"111111111111111104"** | "1" |

* Decoding from JSON

| Language | "1" | "1.0" | "1.6" |
| --- | --- | --- | --- |
| JavaScript™ | 1 (Number) | 1 (Number) | 1.6 (Number) |
| Python | 1 (int) | 1.0 (float) | 1.6 (float) |
| Go | **1 (float64)** | 1 (float64) | 1.6 (float64) |
| Go (expecting `int`) | 1 (int) | **error** | error |
| Haskell (with `:: Int`) | 1 (Int) | 1 (Int) | **2 (Int)** |
| Haskell (with `:: Double`) | 1.0 (Double) | 1.0 (Double) | 1.6 (Double) |
| Rust (with `::<int>`) | 1 (int) | 1 (Int) | **1 (Int)** |
| Rust (with `::<f64>`) | 1 (f64) | 1 (f64) | 1.6 (f64) |

* The tests on Haskell were done using the [json](http://hackage.haskell.org/package/json) package.
* The error message printed by Go was: `cannot unmarshal number 1.0 into Go value of type int`

As you see, there is no uniform behavior. Every implementation follows its own principle. So I think it is reasonable to find a desirable set of behaviors for Rust.

Firstly, every implementation except the one for JavaScript is capable of handling `i64` values. It is even practical, because [Twitter API uses an i64 number to represent a tweet ID](https://dev.twitter.com/overview/api/twitter-ids-json-and-snowflake), although it is recommended to use the string version of the ID.

Secondly, looking into the Go's behavior, implicit type conversion is not allowed in their decoder. If the user expects an integer value to follow, decoding a float value will raise an error. This behavior is desirable in Rust, because we are pleased to follow the principles of strong typing.

Thirdly, Python's JSON module forces a decimal point to be printed even if the fractional part does not exist. This eases the distinction of a float value from an integer value in JSON, because by the spec there is only one type to represent numbers, `Number`.

So, I suggest the following three breaking changes:

1. Remove float preprocessing in serialize::json::Encoder

 `serialize::json::Encoder` currently uses `f64` to emit any integral type. This is possibly due to the behavior of JavaScript, which uses `f64` to represent any numeric value.

 This leads to a problem that only the integers in the range of [-2^53+1, 2^53-1] can be encoded. Therefore, `i64` and `u64` cannot be used reliably in the current implementation.

 [RFC 7159](http://tools.ietf.org/html/rfc7159) suggests that good interoperability can be achieved if the range is respected by implementations. However, it also says that implementations are allowed to set the range of number accepted. And it seems that the JSON encoders outside of the JavaScript world usually make use of `i64` values.

 This commit removes the float preprocessing done in the `emit_*` methods. It also increases performance, because transforming `f64` into String costs more than that of an integral type.

 Fixes #18319

2. Do not coerce to integer when decoding a float value

 When an integral value is expected by the user but a fractional value is found, the current implementation uses `std::num::cast()` to coerce to an integer type, losing the fractional part. This behavior is not desirable because the number loses precision without notice.

 This commit makes it raise `ExpectedError` when such a situation arises.

3. Always use a decimal point when emitting a float value

 JSON doesn't distinguish between integer and float. They are just numbers. Also, in the current implementation, a fractional number without the fractional part is encoded without a decimal point.

 Thereforce, when the value is decoded, it is first rendered as `Json`, either `I64` or `U64`. This reduces type safety, because while the original intention was to cast the value to float, it can also be casted to integer.

 As a workaround of this problem, this commit makes the encoder always emit a decimal point even if it is not necessary. If the fractional part of a float number is zero, ".0" is padded to the end of the result.
2014-12-09 10:51:49 +00:00
bors
c56e59c722 auto merge of #19644 : pcwalton/rust/oibit3, r=nikomatsakis 2014-12-09 07:51:52 +00:00
Patrick Walton
fcd1f53e43 Add some missing Copy implementations 2014-12-08 21:44:04 -08:00
jbranchaud
c09defa070 Change 'Example' to 'Examples' throughout collections' rustdocs. 2014-12-08 23:28:07 -06:00
bors
50b6d01e1c auto merge of #19645 : alexcrichton/rust/old-snap, r=brson
The most recent snapshot was produced on OSX 10.8, but this segfaults on OSX
10.7 so we need to roll back one snapshot so we can start bootstrapping on 10.7
systems again.

cc #19643
2014-12-09 05:01:53 +00:00
Corey Farwell
9af324a673 Remove Result and Option reexports
Brief note: This does *not* affect anything in the prelude

Part of #19253

All this does is remove the reexporting of Result and Option from their
respective modules. More core reexports might be removed, but these ones
are the safest to remove since these enums (and their variants) are included in
the prelude.

[breaking-change]
2014-12-08 21:40:16 -05:00
Niels Egberts
2dc338dfdb Rename assert_eq arguments to left and right.
The names expected and actual are not used anymore in the output. It also
removes the confusion that the argument order is the opposite of junit.
2014-12-09 00:09:42 +00:00
Alex Crichton
456ffcdc56 Revert "Register new snapshots"
This reverts commit 9b443289cf.
2014-12-08 14:30:13 -08:00
Alex Crichton
daafff508c rustc: Prepend a length to all metadata
One of the causes of #19501 was that the metadata on OSX was getting corrupted.
For any one particular invocation of the compiler the metadata file inside of an
rlib archive would have extra bytes appended to the end of it. These extra bytes
end up confusing rbml and have it run off the end of the array (resulting in the
out of bounds detected).

This commit prepends the length of metadata to the start of the metadata to
ensure that we always slice the precise amount that we want, and it also
un-ignores the test from #19502.

Closes #19501
2014-12-08 14:29:24 -08:00
Aaron Weiss
ad7dacd9eb Implemented BorrowFrom<Rc<T>> for T. 2014-12-08 16:32:08 -05:00
bors
eacbd296fa auto merge of #19456 : nikomatsakis/rust/reborrow-closure-arg, r=pnkfelix
Otherwise region inference can fail when closure arguments include `ref` bindings. Test case included in the PR.
2014-12-08 21:31:51 +00:00
Niko Matsakis
9c65a5b150 Link regions in ref bindings from fn arguments. 2014-12-08 15:53:03 -05:00
Niko Matsakis
34812b891d Stop masking overflow and propagate it out more aggressively; also improve error reporting to suggest to user how to fix. 2014-12-08 15:51:38 -05:00
Niko Matsakis
3ee85d828e Kill dead code 2014-12-08 15:51:38 -05:00
Niko Matsakis
87edbea9da Add ability to configure recursion limit.
Fixes #19318.
2014-12-08 15:51:38 -05:00
Niko Matsakis
a16f60b117 Add a feature opt opt_out_copy that allows people to revert to the older
behavior temporarily. This feature will eventually transition to REJECTED.
2014-12-08 13:47:45 -05:00
Niko Matsakis
096a28607f librustc: Make Copy opt-in.
This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.

A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.

For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.

This breaks code like:

    #[deriving(Show)]
    struct Point2D {
        x: int,
        y: int,
    }

    fn main() {
        let mypoint = Point2D {
            x: 1,
            y: 1,
        };
        let otherpoint = mypoint;
        println!("{}{}", mypoint, otherpoint);
    }

Change this code to:

    #[deriving(Show)]
    struct Point2D {
        x: int,
        y: int,
    }

    impl Copy for Point2D {}

    fn main() {
        let mypoint = Point2D {
            x: 1,
            y: 1,
        };
        let otherpoint = mypoint;
        println!("{}{}", mypoint, otherpoint);
    }

This is the backwards-incompatible part of #13231.

Part of RFC #3.

[breaking-change]
2014-12-08 13:47:44 -05:00
bors
84a7615418 auto merge of #19574 : erickt/rust/vec-reserve, r=alexcrichton
(I don't understand why this works, and so I don't quite trust this yet. I'm pushing it up to see if anyone else can replicate this performance increase)

Somehow llvm is able to optimize this version of Vec::reserve into dramatically faster than the old version. In micro-benchmarks this was 2-10 times faster. It also reduce my Rust compile time from 41 minutes to 27 minutes.

Closes #19281.
2014-12-08 18:42:21 +00:00
bors
2e996ffb46 auto merge of #19306 : steveklabnik/rust/gh19269, r=nikomatsakis,brson
Fixes #19269.

/cc @thestinger @mahkoh @mitsuhiko
2014-12-08 16:22:43 +00:00
bors
c7a9b49d1b auto merge of #19560 : sfackler/rust/should-fail-reason, r=alexcrichton
The test harness will make sure that the panic message contains the
specified string. This is useful to help make `#[should_fail]` tests a
bit less brittle by decreasing the chance that the test isn't
"accidentally" passing due to a panic occurring earlier than expected.
The behavior is in some ways similar to JUnit's `expected` feature:
`@Test(expected=NullPointerException.class)`.

Without the message assertion, this test would pass even though it's not
actually reaching the intended part of the code:
```rust
#[test]
#[should_fail(message = "out of bounds")]
fn test_oob_array_access() {
    let idx: uint = from_str("13o").unwrap(); // oops, this will panic
    [1i32, 2, 3][idx];
}
```
2014-12-08 12:12:23 +00:00
Barosl Lee
7176dd1c90 libserialize: Prefer into_string() to to_string() wherever possible
Except for the example code!
2014-12-08 18:19:13 +09:00
Barosl Lee
c32286d1b1 libserialize: Code cleanup 2014-12-08 18:19:13 +09:00
Barosl Lee
fec0f16c98 libserialize: Always use a decimal point when emitting a float value
JSON doesn't distinguish between integer and float. They are just
numbers. Also, in the current implementation, a fractional number
without the fractional part is encoded without a decimal point.

Thereforce, when the value is decoded, it is first rendered as Json,
either I64 or U64. This reduces type safety, because while the original
intention was to cast the value to float, it can also be casted to
integer.

As a workaround of this problem, this commit makes the encoder always
emit a decimal point even if it is not necessary. If the fractional part
of a float number is zero, ".0" is padded to the end of the result.

[breaking-change]
2014-12-08 18:02:53 +09:00
bors
cf0b4e0682 auto merge of #19506 : eddyb/rust/fmt-polish, r=alexcrichton 2014-12-08 09:02:33 +00:00
Barosl Lee
f102123b65 libserialize: Do not coerce to integer when decoding a float value
When an integral value is expected by the user but a fractional value is
found, the current implementation uses std::num::cast() to coerce to an
integer type, losing the fractional part. This behavior is not desirable
because the number loses precision without notice.

This commit makes it raise ExpectedError when such a situation arises.

[breaking-change]
2014-12-08 18:02:12 +09:00
Barosl Lee
ca4f53655e libserialize: Remove float preprocessing in serialize::json::Encoder
serialize::json::Encoder currently uses f64 to emit any integral type.
This is possibly due to the behavior of JavaScript, which uses f64 to
represent any numeric value.

This leads to a problem that only the integers in the range of [-2^53+1,
2^53-1] can be encoded. Therefore, i64 and u64 cannot be used reliably
in the current implementation.

RFC 7159 suggests that good interoperability can be achieved if the
range is respected by implementations. However, it also says that
implementations are allowed to set the range of number accepted. And it
seems that the JSON encoders outside of the JavaScript world usually
make use of i64 values.

This commit removes the float preprocessing done in the emit_* methods.
It also increases performance, because transforming f64 into String
costs more than that of an integral type.

Fixes #18319

[breaking-change]
2014-12-08 18:02:12 +09:00
Eduard Burtescu
15ca63081b test: adjust pretty/issue-4264 for formatting changes. 2014-12-08 09:14:21 +02:00
Eduard Burtescu
fe4fdcc0f6 core: make the public fmt API completely safe. 2014-12-08 09:14:21 +02:00
Eduard Burtescu
c75e8d46c2 core: remove the dead function fmt::argumentstr. 2014-12-08 09:14:21 +02:00
Jon Haddad
956c581111 documentation incorrectly described from_utf8
Docs said from_utf8 accepts a vector when it actually accepts a slice of bytes.
2014-12-07 22:57:40 -08:00
bors
1e69dfa261 auto merge of #19555 : jbranchaud/rust/add-doctests-for-key-values-of-btreemap, r=Gankro 2014-12-08 05:52:28 +00:00
bors
83a44c7fa6 auto merge of #19378 : japaric/rust/no-as-slice, r=alexcrichton
Now that we have an overloaded comparison (`==`) operator, and that `Vec`/`String` deref to `[T]`/`str` on method calls, many `as_slice()`/`as_mut_slice()`/`to_string()` calls have become redundant. This patch removes them. These were the most common patterns:

- `assert_eq(test_output.as_slice(), "ground truth")` -> `assert_eq(test_output, "ground truth")`
- `assert_eq(test_output, "ground truth".to_string())` -> `assert_eq(test_output, "ground truth")`
- `vec.as_mut_slice().sort()` -> `vec.sort()`
- `vec.as_slice().slice(from, to)` -> `vec.slice(from_to)`

---

Note that e.g. `a_string.push_str(b_string.as_slice())` has been left untouched in this PR, since we first need to settle down whether we want to favor the `&*b_string` or the `b_string[]` notation.

This is rebased on top of #19167

cc @alexcrichton @aturon
2014-12-08 02:32:31 +00:00
bors
8bca470c5a auto merge of #19561 : csouth3/rust/treeset-bitops, r=Gankro
Implement the `BitOr`, `BitAnd`, `BitXor`, and `Sub` traits from `std::ops` for TreeSet.  The behavior of these operator overloads is consistent with [RFC 235](https://github.com/rust-lang/rfcs/blob/master/text/0235-collections-conventions.md#combinations).

r? @Gankro
2014-12-08 00:12:30 +00:00
Steven Fackler
a20926a51a Mention expected in testing docs 2014-12-07 16:04:56 -08:00
bluss
a81346966d string: Add test for FromIterator<&str> and Extend<&str> 2014-12-07 23:13:04 +01:00
bluss
56c4e97e83 string: Add test for FromIterator<char> and Extend<char> 2014-12-07 23:12:45 +01:00
Jorge Aparicio
8dcdd1e76a syntax: use UFCS in the expansion of #[deriving(Ord)]
cc #18755
2014-12-07 16:46:46 -05:00
bluss
5ba7c5da62 string: Implement FromIterator<&str> and Extend<&str> for String
&str is a "particle" of a string already, see the graphemes iterator,
so it seems natural that we should be able to use it with Extend.
2014-12-07 22:45:27 +01:00
bluss
d7d5ccf9bb string: Use the iterator size_hint() in .extend() 2014-12-07 21:31:24 +01:00
Steve Klabnik
c8bd9d2beb Remove mention of Dequeue in collections docs.
https://botbot.me/mozilla/rust/2014-12-07/?msg=27003846&page=20
2014-12-07 14:24:57 -05:00
bors
77cd5cc54e auto merge of #19548 : luqmana/rust/mfb, r=nikomatsakis
Fixes #19367.
2014-12-07 19:02:18 +00:00
Peter Atashian
58f12743c2 Make MemoryMap use HANDLE on Windows.
Also fixes some conflicting module names.

Signed-off-by: Peter Atashian <retep998@gmail.com>
2014-12-07 13:25:51 -05:00
bors
558f8d8e3e auto merge of #19539 : cmr/rust/18959, r=nikomatsakis
Closes #18959

Technically, this causes code that once compiled to no longer compile, but
that code probably never ran.

[breaking-change]

------------

Not quite sure the error message is good enough, I feel like it ought to tell you "because it inherits from non-object-safe trait Foo", so I've opened up a follow-up issue #19538
2014-12-07 16:12:22 +00:00