Closed
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
Contributor
Author
|
@bors r+ p=14 rollup=never |
Collaborator
|
📌 Commit 619ed36 has been approved by |
Collaborator
|
⌛ Testing commit 619ed36 with merge ae25bf6d7b6470f4f5379ac7327999d1b7133126... |
Collaborator
|
💔 Test failed - checks-azure |
Contributor
|
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 |
This file contains hidden or 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
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:
SizeOverflowduring mir evaluation #63152 (Always error onSizeOverflowduring mir evaluation)DefKind::Modas "crate" #63250 (diagnostics: Describe crate root modules inDefKind::Modas "crate")Failed merges:
r? @ghost