| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fixes #31546
|
|
This reverts commit c14b615534ebcd5667f594c86d18eebff6afc7cb, reversing
changes made to dda25f2221cc7dd68ed28254665dc7d25e2648ed.
This caused a regression in compiler performance and backporting the fix
to beta was deemed too risky and too challenging, since it is
non-trivial and builds on prior commits in various ways.
Conflicts:
src/librustc/middle/traits/fulfill.rs
src/librustc_data_structures/lib.rs
|
|
Fix #30438.
|
|
Why do this: The RegionGraph representation previously conflated all
of the non-variable regions (i.e. the concrete regions such as
lifetime parameters to the current function) into a single dummy node.
A single dummy node leads DFS on a graph `'a -> '_#1 -> '_#0 -> 'b` to
claim that `'_#1` is reachable from `'_#0` (due to `'a` and `'b` being
conflated in the graph representation), which is incorrect (and can
lead to soundness bugs later on in compilation, see #30438).
Splitting the dummy node ensures that DFS will never introduce new
ancestor relationships between nodes for variable regions in the
graph.
|
|
|
|
After [considerable
pushback](https://github.com/rust-lang/rfcs/issues/1451), it's clear
that there is a community consensus around providing `IpAddr` in the
standard library, together with other APIs using it.
This commit reverts from deprecated status directly to stable. The
deprecation landed in 1.6, which has already been released, so the
stabilization is marked for 1.7 (currently in beta; will require a backport).
|
|
|
|
Following RFC 1462 (amending 550). Closes #31135.
|
|
|
|
Wouldn't want to be able to link to this on stable Rust!
Conflicts:
src/librustc_mir/lib.rs
|
|
This commit implements the stabilization of the custom hasher support intended
for 1.7 but left out due to some last-minute questions that needed some
decisions. A summary of the actions done in this PR are:
Stable
* `std::hash::BuildHasher`
* `BuildHasher::Hasher`
* `BuildHasher::build_hasher`
* `std::hash::BuildHasherDefault`
* `HashMap::with_hasher`
* `HashMap::with_capacity_and_hasher`
* `HashSet::with_hasher`
* `HashSet::with_capacity_and_hasher`
* `std::collections::hash_map::RandomState`
* `RandomState::new`
Deprecated
* `std::collections::hash_state`
* `std::collections::hash_state::HashState` - this trait was also moved into
`std::hash` with a reexport here to ensure that we can have a blanket impl to
prevent immediate breakage on nightly. Note that this is unstable in both
location.
* `HashMap::with_hash_state` - renamed
* `HashMap::with_capacity_and_hash_state` - renamed
* `HashSet::with_hash_state` - renamed
* `HashSet::with_capacity_and_hash_state` - renamed
Closes #27713
|
|
r? @steveklabnik
|
|
Fixes #30655
|
|
|
|
Supersedes https://github.com/rust-lang/rust/pull/30517
Fixes https://github.com/rust-lang/rust/issues/29575
cc @luqmana
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Successful merges: #30981, #30982, #30986, #30987, #30988, #30990, #30998
- Failed merges:
|
|
|
|
CC #30642
r? @Gankro
|
|
Fix spacing style of `T: Bound` in docs
The space between `T` and `Bound` is the typical style used in code and
produced by rustdoc's rendering. Fixed first in Reflect's docs and then
I fixed all occurrences in docs I could find.
|
|
Sorry for nitpicking, but I think the example of the expanded macro should be wrapped inside a pair of curly braces to match the macro definition. Also the current example triggers a variable redefinition error.
|
|
Original: #30968 (My first PR was targeting the wrong branch)
|
|
|
|
We currently pass generic as the CPU to LLVM. This results in worse
than required code generation. On little endian, which is only POWER8,
we avoid many POWER4 and newer instructions.
Pass ppc64 and ppc64le instead.
|
|
Restore indexed formulation of clone_from_slice
For good codegen here, we need a lock step iteration where the loop
bound is only checked once per iteration; .zip() unfortunately does not
optimize this way.
If we use a counted loop, and make sure that llvm sees that the bounds
check condition is the same as the loop bound condition, the bounds
checks are optimized out. For this reason we need to slice `from`
(apparently) redundantly.
This commit restores the old formulation of clone_from_slice. In this
shape, clone_from_slice will again optimize into calling memcpy where possible
(for example for &[u8] or &[i32]).
|
|
For good codegen here, we need a lock step iteration where the loop
bound is only checked once per iteration; .zip() unfortunately does not
optimize this way.
If we use a counted loop, and make sure that llvm sees that the bounds
check condition is the same as the loop bound condition, the bounds
checks are optimized out. For this reason we need to slice `from`
(apparently) redundantly.
This commit restores the old formulation of clone_from_slice. In this
shape, clone_from_slice will again optimize into calling memcpy where possible
(for example for &[u8] or &[i32]).
|
|
Encountered while I was trying to work on #28518. Please let me know whether this is a correct move.
|
|
CC #30642
|
|
it makes no sense here, accidentally introduced in #30931
r? @dotdash
|
|
it makes no sense here, accidentally introduced in #30931
|
|
|
|
|
|
This takes the approach of making `NodeRef` universally covariant.
Fixes #30979.
|
|
I don’t understand what the "flow information" of an IPv6 address is, but it looks separate from the scope ID. This was probably a copy/paste error.
|
|
r? @Manishearth
|
|
The space between `T` and `Bound` is the typical style used in code and
produced by rustdoc's rendering. Fixed first in Reflect's docs and then
I fixed all occurrences in docs I could find.
|
|
|
|
We currently pass generic as the CPU to LLVM. This results in worse
than required code generation. On little endian, which is only POWER8,
we avoid many POWER4 and newer instructions.
Pass ppc64 and ppc64le instead.
|
|
recognize that it should error
|
|
r? @aturon
|
