This commit deprecates a few more in-tree libs for their crates.io counterparts.
Note that this commit does not make use of the #[deprecated] tag to prevent
warnings from being generated for in-tree usage. Once #[unstable] warnings are
turned on then all external users will be warned to move.
These crates have all been duplicated in rust-lang/$crate repositories so
development can happen independently of the in-tree copies. We can explore at a
later date replacing the in-tree copies with the external copies, but at this
time the libraries have changed very little over the past few months so it's
unlikely for changes to be sent to both repos.
cc #19260
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)]
^~~
```
This patch does not itself enable generalized where clauses, but it lays the groundwork. Rather than storing a list of bounds per type parameter, the trait selection and other logic is now driven by a unified list of predicates. All predicate handling is now driven through a common interface. This also fixes a number of bugs where region predicates were being dropped on the floor. As a drive-by, this patch also fixes some bugs in the opt-out-copy feature flag.
That said, this patch does not change the parser or AST in any way, so we still *generate* the list of predicates by walking a list of bounds (and we still *store* the bounds on the `TypeParameterDef` and so on). Those will get patched in a follow-up.
The commits in this case are standalone; the first few are simple refactorings.
r? @nick29581
cc @aturon
in most cases, just the error message changed, but in some cases we
are reporting new errors that OUGHT to have been reported before but
we're overlooked (mostly involving the `'static` bound on `Send`).
These probably happened during the merge of the commit that made `Copy` opt-in.
Also, convert the last occurence of `/**` to `///` in `src/libstd/num/strconv.rs`
This is a first pass at insert on RingBuf. I tried to keep it as simple as possible. I'm not sure of the performance implications of doing one copy vs. copying multiple times but moving a smaller amount of memory. I chose to stick with one copy, even if the amount of memory I have to move is larger.
I believe this is part of #18424
@Gankro mentioned this was missing.
Build `clean::ConstantItem` values in the `inline` module and
pretty-print the AST for inlined const items.
Doc strings are still missing from inlined constants (see #19773).
Partially address #18156, #19722, #19185Fix#15821
This pull request tries to fix#19340, which states two ICE cases related to enum struct variants.
It is my first attempt to fix the compiler. I found this solution by trial and error, so the method used to fix the issue looks very hacky. Please review it, and direct me to find a better solution.
I'm also to add test cases. Where should I put them? Maybe `src/test/run-pass/issue-19340.rs`?
I am trying to add an implementation of `bitor` for `BTreeSet`. I think I am most of the way there, but I am going to need some guidance to take it all the way.
When I run `make check`, I get:
```
error: cannot move out of dereference of `&`-pointer
self.union(_rhs).map(|&i| i).collect::<BTreeSet<T>>()
^~
```
I'd appreciate any nudges in the right direction. If I can figure this one out, I am sure I will be able to implement `bitand`, `bitxor`, and `sub` as well.
/cc @Gankro
---
**Update**
I have added implementations for `BitOr`, `BitAnd`, `BitXor`, and `Sub` for `BTreeSet`.
Add initial attempt at implementing BitOr for BTreeSet.
Update the implementation of the bitor operator for BTreeSets.
`make check` ran fine through this.
Add implementations for BitAnd, BitXor, and Sub as well.
Remove the FIXME comment and add unstable flags.
Add doctests for the bitop functions.
The current behavior leads to adjustments like `&&*` being applied
instead of just `&` (when the unmodified receiver is a `&T` or an `&mut
T`). This causes both safety errors and unexpected behavior. The safety
errors result from regionck not being prepared for auto-ref-ref-like
adjustments; this is worth fixing on its own, but I think the best way
to do it is to modify regionck to use expr-use-visitor (and fix
expr-use-visitor as well, which I don't think properly invokes `borrow`
for each level of auto-ref), and for now it's simpler to just not
produce the adjustment in question. (I have a separate patch porting
regionck to use exprusevisitor for a different bug, so that is coming.)
Previously, the DeBruijn index for the self type was not being
adjusted to account for the fn binder. This mean that when late-bound
regions were instantiated, you sometimes wind up with two distinct
lifetimes.
Fixes#19537.
This detects (a subset of) the cases when `transmute::<T, U>(x)` can be
lowered to a direct `bitcast T x to U` in LLVM. This assists with
efficiently handling a SIMD vector as multiple different types,
e.g. swapping bytes/words/double words around inside some larger vector
type.
C compilers like GCC and Clang handle integer vector types as `__m128i`
for all widths, and implicitly insert bitcasts as required. This patch
allows Rust to express this, even if it takes a bit of `unsafe`, whereas
previously it was impossible to do at all without inline assembly.
Example:
pub fn reverse_u32s(u: u64x2) -> u64x2 {
unsafe {
let tmp = mem::transmute::<_, u32x4>(u);
let swapped = u32x4(tmp.3, tmp.2, tmp.1, tmp.0);
mem::transmute::<_, u64x2>(swapped)
}
}
Compiling with `--opt-level=3` gives:
Before
define <2 x i64> @_ZN12reverse_u32s20hbdb206aba18a03d8tbaE(<2 x i64>) unnamed_addr #0 {
entry-block:
%1 = bitcast <2 x i64> %0 to i128
%u.0.extract.trunc = trunc i128 %1 to i32
%u.4.extract.shift = lshr i128 %1, 32
%u.4.extract.trunc = trunc i128 %u.4.extract.shift to i32
%u.8.extract.shift = lshr i128 %1, 64
%u.8.extract.trunc = trunc i128 %u.8.extract.shift to i32
%u.12.extract.shift = lshr i128 %1, 96
%u.12.extract.trunc = trunc i128 %u.12.extract.shift to i32
%2 = insertelement <4 x i32> undef, i32 %u.12.extract.trunc, i64 0
%3 = insertelement <4 x i32> %2, i32 %u.8.extract.trunc, i64 1
%4 = insertelement <4 x i32> %3, i32 %u.4.extract.trunc, i64 2
%5 = insertelement <4 x i32> %4, i32 %u.0.extract.trunc, i64 3
%6 = bitcast <4 x i32> %5 to <2 x i64>
ret <2 x i64> %6
}
_ZN12reverse_u32s20hbdb206aba18a03d8tbaE:
.cfi_startproc
movd %xmm0, %rax
punpckhqdq %xmm0, %xmm0
movd %xmm0, %rcx
movq %rcx, %rdx
shrq $32, %rdx
movq %rax, %rsi
shrq $32, %rsi
movd %eax, %xmm0
movd %ecx, %xmm1
punpckldq %xmm0, %xmm1
movd %esi, %xmm2
movd %edx, %xmm0
punpckldq %xmm2, %xmm0
punpckldq %xmm1, %xmm0
retq
After
define <2 x i64> @_ZN12reverse_u32s20hbdb206aba18a03d8tbaE(<2 x i64>) unnamed_addr #0 {
entry-block:
%1 = bitcast <2 x i64> %0 to <4 x i32>
%2 = shufflevector <4 x i32> %1, <4 x i32> undef, <4 x i32> <i32 3, i32 2, i32 1, i32 0>
%3 = bitcast <4 x i32> %2 to <2 x i64>
ret <2 x i64> %3
}
_ZN12reverse_u32s20hbdb206aba18a03d8tbaE:
.cfi_startproc
pshufd $27, %xmm0, %xmm0
retq
- 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.
Unlike a tuple variant constructor which can be called as a function, a
struct variant constructor is not a function, so cannot be called.
If the user tries to assign the constructor to a variable, an ICE
occurs, because there is no way to use it later. So we should stop the
constructor from being used like that.
A similar mechanism already exists for a normal struct, as it prohibits
a struct from being resolved. This commit does the same for a struct
variant.
This commit also includes some changes to the existing tests.
Fixes#19452.
When a type error occurs, `check_method_argument_types()` tries to provide arguments filled with `ty::mk_err()`. However, if a function takes the parameters as a tuple, the arguments should be converted to a tuple before passing it to `check_argument_types()`.
Fixes#19521.
When a type error occurs, check_method_argument_types() tries to provide
arguments filled with ty::mk_err(). However, if a function takes the
parameters as a tuple, the arguments should be converted to a tuple
before being passed to check_argument_types().
Fixes#19521.
- Remove the `for Sized?` bound on `core::ops::FnOnce`, as it takes `self` by value and can never be implemented by an unsized type.
- Add a missing `Sized?` bound to the blanket `core::ops::FnMut` impl, as both `Fn` and `FnMut` are `for Sized?`.
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
These probably happened during the merge of the commit that made `Copy` opt-in.
Also, convert the last occurence of `/**` to `///` in `src/libstd/num/strconv.rs`
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.
Depends on https://github.com/rust-lang/rust/pull/19407 which is merged, but might need a new snapshot
[breaking-change]
Strings iterate to both char and &str, so it is natural it can also be extended or collected from an iterator of &str.
Apart from the trait implementations, `Extend<char>` is updated to use the iterator size hint, and the test added tests both the char and the &str versions of Extend and FromIterator.
- Support gcc-less installation on Windows. To do so in unattended mode run:`<intaller>.exe /TYPE=compact /SILENT`.
- Do not require admin privileges to install.
cc #19519
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]
I'm interested in including doctests for `BTreeMap`'s `iter_mut` and `into_iter` methods in this PR as well, but I am not sure of the best way to demonstrate/test what they do for the doctests.
This means that `Fn(&A) -> (&B, &C)` is equivalent to `for<'a> Fn(&'a A)
-> (&'a B, &'a C)` similar to the lifetime elision of lower-case `fn` in
types and declarations.
Closes#18992.
Reported as a part of rust-lang/rust#19120
The logic of rust-lang/rust@74fb798a20 was
flawed because when a CI tool run the test parallely with other tasks,
they all belong to a single session family and the test may pick up
irrelevant zombie processes before they are reaped by the CI tool
depending on timing.
detect UFCS drop and allow UFCS methods to have explicit type parameters.
Work towards #18875.
Since code could previously call the methods & implement the traits
manually, this is a
[breaking-change]
Closes#19586. Closes#19375.
- 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.
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.
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]
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
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.
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
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]
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