Rollup of 16 pull requests #59151
Merged
Rollup of 16 pull requests #59151
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Done previously as a part of rust-lang#58748
Type checking associated constants can require trait bounds, but an empty parameter environment was provided to the trait solver. Providing an appropriate parameter environment seems to fix rust-lang#54822 and also make one of the cases in src/test/ui/nll/trait-associated-constant.rs that should compile successfully do so. It also (slightly) improves the error message in src/test/ui/associated-const/associated-const-generic-obligations.rs
This updates the final example in the documentation for the types `Range`, `RangeFrom`, `RangeFull`, `RangeInclusive`, `RangeTo`, `RangeToInclusive`.
In the `issue-53548` test added in this commit, the `Box<dyn Trait>`
type is expanded to `Box<dyn Trait + 'static>`, but the generator
"witness" that results is `for<'r> { Box<dyn Trait + 'r> }`. The WF
code was encountering an ICE (when debug-assertions were enabled) and
an unexpected compilation error (without debug-asserions) when trying
to process this `'r` region bound. In particular, to be WF, the region
bound must meet the requirements of the trait, and hence we got
`for<'r> { 'r: 'static }`. This would ICE because the `Binder`
constructor we were using was assering that no higher-ranked regions
were involved (because the WF code is supposed to skip those). The
error (if debug-asserions were disabled) came because we obviously
cannot prove that `'r: 'static` for any region `'r`. Pursuant with
our "lazy WF" strategy for higher-ranked regions, the fix is not to
require that `for<'r> { 'r: 'static }` holds (this is also analogous
to what we would do for higher-ranked regions appearing within the
trait in other positions).
librustc_interface: Update scoped-tls to 1.0 Done previously as a part of rust-lang#58748. r? @Zoxc
…henkov Parse lifetimes that start with a number and give specific error Fix rust-lang#58786.
Update rand version cc: rust-lang#57724 r? @scottmcm
Fix documentation of from_ne_bytes and from_le_bytes Copypasta mistake, the documentation of `from_ne_bytes` and `from_le_bytes` used the big-endian variant in the example snippets.
…ackler
Use lifetime contravariance to elide more lifetimes in core+alloc+std
Sample:
```diff
- impl<'a, 'b, A: ?Sized, B: ?Sized> PartialEq<&'b mut B> for &'a mut A where A: PartialEq<B> {
+ impl<A: ?Sized, B: ?Sized> PartialEq<&mut B> for &mut A where A: PartialEq<B> {
#[inline]
- fn eq(&self, other: &&'b mut B) -> bool { PartialEq::eq(*self, *other) }
+ fn eq(&self, other: &&mut B) -> bool { PartialEq::eq(*self, *other) }
#[inline]
- fn ne(&self, other: &&'b mut B) -> bool { PartialEq::ne(*self, *other) }
+ fn ne(&self, other: &&mut B) -> bool { PartialEq::ne(*self, *other) }
}
```
[I didn't know this worked](https://internals.rust-lang.org/t/why-can-you-use-different-unconstrained-lifetimes-to-implement-traits/9544/2?u=scottmcm) until recently, but since defining methods contravariantly in their lifetimes this way has worked back to Rust 1.0, we might as well take advantage of combining it with IHLE.
…ation, r=shepmaster Standardize `Range*` documentation This updates the final example in the documentation for the types `Range`, `RangeFrom`, `RangeFull`, `RangeInclusive`, `RangeTo`, `RangeToInclusive`.
…frewsxcv Fix incorrect links in librustc_codegen_llvm documentation
Fix rust-lang#54822 and associated faulty tests Type checking associated constants can require trait bounds, but an empty parameter environment was provided to the trait solver. Providing an appropriate parameter environment seems to fix rust-lang#54822 and also make one of the cases in src/test/ui/nll/trait-associated-constant.rs that should compile successfully do so. It also (slightly) improves the error message in src/test/ui/associated-const/associated-const-generic-obligations.rs
Remove precompute_in_scope_traits_hashes r? @michaelwoerister
…=oli-obk Reduces Code Repetitions like `!n >> amt` Fixes rust-lang#49937 . This PR contains defining a function which operates bit inversion and reducing bit operation like `!0u128 >> (128 - size.bits())`.
…ater, r=Centril impl FromIterator for Result: Use assert_eq! instead of assert!
Replace assert with assert_eq Use `assert_eq!` instead of `assert!` for the tests
Visit impl Trait for dead_code lint Fix rust-lang#59085.
Note that NonNull does not launder shared references for mutation See https://users.rust-lang.org/t/relative-pointer-an-abstraction-to-build-movable-self-referential-types/26186/6
…bound, r=pnkfelix
ignore higher-ranked object bound conditions created by WF
In the `issue-53548` test added in this PR, the `Box<dyn Trait>` type is expanded to `Box<dyn Trait + 'static>`, but the generator "witness" that results is `for<'r> { Box<dyn Trait + 'r> }`. The WF code was encountering an ICE (when debug-assertions were enabled) and an unexpected compilation error (without debug-asserions) when trying to process this `'r` region bound. In particular, to be WF, the region bound must meet the requirements of the trait, and hence we got `for<'r> { 'r: 'static }`. This would ICE because the `Binder` constructor we were using was assering that no higher-ranked regions were involved (because the WF code is supposed to skip those). The error (if debug-asserions were disabled) came because we obviously cannot prove that `'r: 'static` for any region `'r`. Pursuant with
our "lazy WF" strategy for higher-ranked regions, the fix is not to require that `for<'r> { 'r: 'static }` holds (this is also analogous to what we would do for higher-ranked regions appearing within the trait in other positions).
Fixes rust-lang#53548
r? @pnkfelix
… r=sfackler
Simplify Iterator::{min, max}
This PR simplifies the `select_fold1` helper method used to implmement `Iterator::{min, min_by, min_by_key, max, max_by, max_by_key}` by removing the projection argument, which was only used by the implementations of `min_by_key` and `max_by_key`.
I also added tests to ensure that the stability as mentioned in the comments of `min` and `max` is preserved, and fixed the `iter::{bench_max, bench_max_by_key}` benchmarks which the compiler presumably was able to collapse into closed-form expressions. None of the benchmark results were impacted, I suspect their generated assembly didn't change.
|
@bors r+ p=16 |
|
📌 Commit 73feddb has been approved by |
bors
added
the
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Mar 13, 2019
Rollup of 16 pull requests Successful merges: - #58829 (librustc_interface: Update scoped-tls to 1.0) - #58876 (Parse lifetimes that start with a number and give specific error) - #58908 (Update rand version) - #58998 (Fix documentation of from_ne_bytes and from_le_bytes) - #59056 (Use lifetime contravariance to elide more lifetimes in core+alloc+std) - #59057 (Standardize `Range*` documentation) - #59080 (Fix incorrect links in librustc_codegen_llvm documentation) - #59083 (Fix #54822 and associated faulty tests) - #59093 (Remove precompute_in_scope_traits_hashes) - #59101 (Reduces Code Repetitions like `!n >> amt`) - #59121 (impl FromIterator for Result: Use assert_eq! instead of assert!) - #59124 (Replace assert with assert_eq) - #59129 (Visit impl Trait for dead_code lint) - #59130 (Note that NonNull does not launder shared references for mutation) - #59132 (ignore higher-ranked object bound conditions created by WF) - #59138 (Simplify Iterator::{min, max}) Failed merges: r? @ghost
|
☀️ Test successful - checks-travis, status-appveyor |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Range*documentation #59057 (StandardizeRange*documentation)!n >> amt#59101 (Reduces Code Repetitions like!n >> amt)Failed merges:
r? @ghost