-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 7 pull requests #72638
Rollup of 7 pull requests #72638
Conversation
Use raw pointers to avoid making any assertions about the data field.
Fixes rust-lang#72590 With PR rust-lang#70551, observing a `ty::Error` guarantees that compilation is going to fail. Therefore, there are no soundness impliciations to continuing on when we encounter a `ty::Error` - we can only affect whether or not additional error messags are emitted. By not bailing out, we avoid incorrectly determining that types are `!Sized` when a type error is present, which allows us to avoid emitting additional spurious error messages. The original comment mentioned this code being shared by coherence - howver, this change resulted in no diagnostic changes in any of the existing tests.
confusing diagnostics, issue rust-lang#72253 add test for confusing error message, issue-72253 remove is_multiline check, refactor to self.expect(&token:Semi) update issue-72253 tests return Ok
Fix confusing error message for comma typo in multiline statement Fixes rust-lang#72253. Expands on the issue with a colon typo check. r? @estebank cc @ehuss
…matsakis Make `PolyTraitRef::self_ty` return `Binder<Ty>` This came up during review of rust-lang#71618. The current implementation is the same as a call to `skip_binder` but harder to audit. Make it preserve binding levels and add a call to `skip_binder` at all use sites so they can be audited as part of rust-lang#72507.
Resolve UB in Arc/Weak interaction (2) Use raw pointers to avoid making any assertions about the data field. Follow up from rust-lang#72479, see that PR for more detail on the motivation. @RalfJung I was able to avoid a lot of the changes to `Weak`, by making a helper type (`WeakInner`) - because of auto-deref and because the fields have the same name, the rest of the code continues to compile.
…=nikomatsakis Add test for old compiler ICE when using `Borrow` The original issue was caused by implementing `Borrow` on a local type and using the tokio-reactor crate which had this impl: https://github.com/tokio-rs/tokio/blob/tokio-0.1.4/tokio-reactor/src/poll_evented.rs#L547-L577 This causes an ICE on Rust 1.27.0: ```console $ RUSTUP_TOOLCHAIN=1.27.0 rustc src/test/ui/issues/issue-50687-ice-on-borrow.rs error: internal compiler error: librustc/traits/structural_impls.rs:180: impossible case reached thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:554:9 note: Run with `RUST_BACKTRACE=1` for a backtrace. error: aborting due to previous error note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports note: rustc 1.27.0 (3eda71b 2018-06-19) running on x86_64-apple-darwin ``` Closes rust-lang#50687
… r=Dylan-DPC Small cell example update r? @Dylan-DPC
…=nikomatsakis Don't bail out of trait selection when predicate references an error Fixes rust-lang#72590 With PR rust-lang#70551, observing a `ty::Error` guarantees that compilation is going to fail. Therefore, there are no soundness impliciations to continuing on when we encounter a `ty::Error` - we can only affect whether or not additional error messags are emitted. By not bailing out, we avoid incorrectly determining that types are `!Sized` when a type error is present, which allows us to avoid emitting additional spurious error messages. The original comment mentioned this code being shared by coherence - howver, this change resulted in no diagnostic changes in any of the existing tests.
…olnay Add remark regarding DoubleEndedIterator While reviewing rust-itertools/itertools@14293bd#diff-2c16d2ada06ad2fd1fc754679646d471, I realized that a `DoubleEndedIterator` may yield different elements depending on whether it is traversed forwards or backwards. (Not only the *order*, but possibly also the yielded values.) I found this remarkable, but could not find anything in the current docs, so I thought it may be worth mentioning this explicitly. Unfortunately, I could not test these changes locally (`rustdoc` complains about `unresolved import`). Sorry if this causes headache. If I should change something, please let me know. If it seems too trivial, feel free to just close this PR.
@bors r+ rollup=never p=7 |
📌 Commit 1ef8491 has been approved by |
⌛ Testing commit 1ef8491 with merge 19d65819bd2f989e040f609188b6495827e3eac3... |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Successful merges:
PolyTraitRef::self_ty
returnBinder<Ty>
#72508 (MakePolyTraitRef::self_ty
returnBinder<Ty>
)Borrow
#72548 (Add test for old compiler ICE when usingBorrow
)Failed merges:
r? @ghost