Implement some trivial size_hints for various iterators
This also implements ExactSizeIterator where applicable.
Addresses most of the Iterator traits mentioned in #23708.
I intend to do more, but I don't want to make the PR too large.
optimize NLL constraint propagation a little
Removes a bone-headed hot spot in NLL constant propagation; we were re-allocating the stack vector and hashmap as we repeated the DFS. This change shares those resources across each call.
It also modifies the constraint list to be a linked list; arguably I should revert that, though, as this didn't turn out to be a perf hit and perhaps the old code was clearer? (Still, the new style appeals to me.)
r? @pnkfelix
Revert "Add TryFrom and TryInto to the prelude"
This reverts commit 09008cc23f.
This addition landed in https://github.com/rust-lang/rust/pull/49305 and turned out to break crates that had their own copy of `TryFrom` in order to use it on the Stable channel :(
We’ll explore the possibility of the 2018 edition having a different prelude that includes this traits. However per the editions RFC this requires implementing a warning in the 2015 edition for code that *would* break.
rustc: Forbid #[inline(always)] with #[target_feature]
Once a target feature is enabled for a function that means that it in general
can't be inlined into other functions which don't have that target feature
enabled. This can cause both safety and LLVM issues if we were to actually
inline it, so `#[inline(always)]` both can't be respected and would be an error
if we did so!
Today LLVM doesn't inline functions with different `#[target_feature]`
annotations, but it turns out that if one is tagged with `#[inline(always)]`
it'll override this and cause scary LLVM error to arise!
This commit fixes this issue by forbidding these two attributes to be used in
conjunction with one another.
Closesrust-lang-nursery/stdsimd#404
Use f{32,64}::to_bits for is_zero test in vec::SpecFromElem
vec::SpecFromElem provides an optimization to use calloc to fill a Vec
when the element given to fill the Vec is represented by 0.
For floats, the test for that currently used is `x == 0. &&
x.is_sign_positive()`. When compiled in a standalone function, rustc
generates the following assembly:
```
xorps xmm1, xmm1
ucomisd xmm0, xmm1
setnp al
sete cl
and cl, al
movq rax, xmm0
test rax, rax
setns al
and al, cl
ret
```
A simpler test telling us whether the value is represented by 0, is
`x.to_bits() == 0`, which rustc compiles to:
```
movq rax, xmm0
test rax, rax
sete al
ret
```
Not that the test is hot in any way, but it also makes it clearer what
the intent in the rust code is.
rustbuild: Don't leak file handles when creating junctions on Windows
This fixes building the compiler docs because stage1-rustc\x86_64-pc-windows-msvc\doc is used twice which doesn't work if we still have a handle from the first time.
rustc: Group linked libraries where needed
This commit fixes a longstanding issue with the compiler with circular
dependencies between libcore and libstd. The `core` crate requires at least one
symbol, the ability to unwind. The `std` crate is the crate which actually
defines this symbol, but the `std` crate also depends on the `core` crate.
This circular dependency is in general disallowed in Rust as crates cannot have
cycles amongst them. A special exception is made just for core/std, but this is
also unfortunately incompatible with how GNU linkers work. GNU linkers will
process undefined symbols in a left-to-right fashion, only actually linking an
rlib like libstd if there are any symbols used from it. This strategy is
incompatible with circular dependencies because if we otherwise don't use
symbols from libstd we don't discover that we needed it until we're later
processing libcore's symbols!
To fix this GNU linkers support the `--start-group` and `--end-group` options
which indicate "libraries between these markers may have circular dependencies
amongst them. The linker invocation has been updated to automatically pass these
arguments when we're invoking a GNU linker and automatically calculate where the
arguments need to go (around libstd and libcore)
Closes#18807Closes#47074
This commit fixes a longstanding issue with the compiler with circular
dependencies between libcore and libstd. The `core` crate requires at least one
symbol, the ability to unwind. The `std` crate is the crate which actually
defines this symbol, but the `std` crate also depends on the `core` crate.
This circular dependency is in general disallowed in Rust as crates cannot have
cycles amongst them. A special exception is made just for core/std, but this is
also unfortunately incompatible with how GNU linkers work. GNU linkers will
process undefined symbols in a left-to-right fashion, only actually linking an
rlib like libstd if there are any symbols used from it. This strategy is
incompatible with circular dependencies because if we otherwise don't use
symbols from libstd we don't discover that we needed it until we're later
processing libcore's symbols!
To fix this GNU linkers support the `--start-group` and `--end-group` options
which indicate "libraries between these markers may have circular dependencies
amongst them. The linker invocation has been updated to automatically pass these
arguments when we're invoking a GNU linker and automatically calculate where the
arguments need to go (around libstd and libcore)
Closes#18807Closes#47074
Rename RangeArgument to RangeBounds, move it and Bound to libcore
As proposed in the tracking issue: https://github.com/rust-lang/rust/issues/30877
Changes to *stable* items:
* `core::ops::Bound` / `std::ops::Bound` is new
* `std::collections::Bound` is a deprecated reexport of it (does this actually cause a warning?)
Changes to *unstable* items
* `alloc::Bound` is gone
* `alloc::range::RangeArgument` is moved to `core::ops::RangeBounds` / `std::ops::RangeBounds`
* `alloc::range` is gone
* `std::collections::range::RangeArgument` is deprecated reexport, to be removed later
* `std::collections::range` is deprecated, to be removed later
* `impl RangeBounds<T> for Range{,From,To,Inclusive,ToInclusive}<&T>` are added
The idea of replacing this trait with a type to be used with `Into<_>` is left for future consideration / work.
(Fixes https://github.com/rust-lang-nursery/rust-clippy/issues/2552.)
