-
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 14 pull requests #63309
Rollup of 14 pull requests #63309
Conversation
…dation step Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
Co-Authored-By: Aleksey Kladov <aleksey.kladov@gmail.com>
This was missed in PR rust-lang#62293.
Co-Authored-By: Aleksey Kladov <aleksey.kladov@gmail.com>
This is just needless indirection.
…scottmcm Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take} Now that `DoubleEndedIterator::nth_back` has landed, `StepBy` and `Take` can have an efficient `DoubleEndedIterator` implementation. I don't know if there was any particular reason for `Peekable` not having a `DoubleEndedIterator` implementation, but it's quite trivial and I don't see any drawbacks to having it. I'm not very happy about the implementation of `Peekable::try_rfold`, but I didn't see another way to only take the value out of `self.peeked` in case `self.iter.try_rfold` didn't exit early. I only added `Peekable::rfold` (in addition to `try_rfold`) because its `Iterator` implementation has both `fold` and `try_fold` (and for similar reasons I added `Take::try_rfold` but not `Take::rfold`). Do we have any guidelines on whether we want both? If we do want both, maybe we should investigate which iterator adaptors override `try_fold` but not `fold` and add the missing implementations. At the moment I think that it's better to always have iterator adaptors implement both, because some iterators have a simpler `fold` implementation than their `try_fold` implementation. The tests that I added may not be sufficient because they're all just existing tests where `next`/`nth`/`fold`/`try_fold` are replaced by their DEI counterparts, but I do think all paths are covered. Is there anything in particular that I should probably also test?
…omasdezeeuw Add {IoSlice, IoSliceMut}::advance API inspired by the [`Buf::advance`](https://docs.rs/bytes/0.4.12/bytes/trait.Buf.html#tymethod.advance) method found in the [bytes](https://docs.rs/bytes) crate. Closes rust-lang#62726.
Remove special code-path for handing unknown tokens In `StringReader`, we have a buffer of fatal errors, which is used only in a single case: when we see something which is not a reasonable token at all, like `🦀`. I think a more straightforward thing to do here is to produce an explicit error token in this case, and let the next layer (the parser), deal with it. However currently this leads to duplicated error messages. What should we do with this? Naively, I would think that emitting (just emitting, not raising) `FatalError` should stop other errors, but looks like this is not the case? We can also probably tweak parser on the case-by-case basis, to avoid emitting "expected" errors if the current token is an `Err`. I personally also fine with cascading errors in this case: it's quite unlikely that you actually type a fully invalid token. @petrochenkov, which approach should we take to fight cascading errors?
Always error on `SizeOverflow` during mir evaluation Fix rust-lang#55878, fix rust-lang#25116. r? @oli-obk
Explaining the reason why validation is performed in to_str of path.rs I thought it's good to explain the reason for the validation during the conversion between Path/PathBuffer into str, which explains the reason for returning an Option at this point (good for beginners who are reading through the docs).
diagnostics: Describe crate root modules in `DefKind::Mod` as "crate" Or we can use "extern crate" like resolve previously did sometimes, not sure. r? @davidtwco
…, r=Centril Add tests for some issues Closes rust-lang#29265 Closes rust-lang#37433 Closes rust-lang#49544 r? @Centril
fix UB in a test We used to compare two mutable references that were supposed to point to the same thing. That's no good. Compare them as raw pointers instead.
…rors, r=estebank Revert "Rollup merge of rust-lang#62696 - chocol4te:fix_#62194, r=estebank" This reverts commit df21a6f (rust-lang#62696), reversing changes made to cc16d04. That PR makes error messages worse than before, and we couldn't come up with a way of actually making them better, so revert it for now. Any idea for making this error message better is welcome! Fixes rust-lang#63145. r? @estebank
…chenkov Some more libsyntax::attr cleanup Much smaller patch than the last one, mostly just finishing up by removing some Span arguments. r? @petrochenkov
…Centril Remove leftover AwaitOrigin This was missed in PR rust-lang#62293.
Don't store &Span This is just needless indirection.
improve align_offset docs Cc @shepmaster
…=oli-obk Make qualify consts in_projection use PlaceRef r? @oli-obk
@bors r+ p=14 rollup=never |
📌 Commit 619ed36 has been approved by |
⌛ Testing commit 619ed36 with merge ae25bf6d7b6470f4f5379ac7327999d1b7133126... |
💔 Test failed - checks-azure |
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:
SizeOverflow
during mir evaluation #63152 (Always error onSizeOverflow
during mir evaluation)DefKind::Mod
as "crate" #63250 (diagnostics: Describe crate root modules inDefKind::Mod
as "crate")Failed merges:
r? @ghost