Rollup of 14 pull requests #63311
Closed
Rollup of 14 pull requests #63311
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
…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.
This is one of the behaviors we no longer allow in NLL. Since it can lead to undefined behavior, I think it's definitely worth making it a hard error without waiting to turn off migration mode (rust-lang#58781). Closes rust-lang#60450. My ulterior motive here is making it impossible to leave variables partially initialized across a yield (see discussion at rust-lang#63035), so tests are included for that.
…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?
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?
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).
…ized, r=Centril Make use of possibly uninitialized data [E0381] a hard error This is one of the behaviors we no longer allow in NLL. Since it can lead to undefined behavior, I think it's definitely worth making it a hard error without waiting to turn off migration mode (rust-lang#58781). Closes rust-lang#60450. My ulterior motive here is making it impossible to leave variables partially initialized across a yield (see rust-lang#60889, discussion at rust-lang#63035), so tests are included for that. cc rust-lang#54987 --- I'm not sure if bypassing the buffer is a good way of doing this. We could also make a `force_errors_buffer` or similar that gets recombined with all the errors as they are emitted. But this is simpler and seems fine to me. r? @Centril cc @cramertj @nikomatsakis @pnkfelix @RalfJung
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 a988d59 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit a988d59 with merge b80e8f1808fe72f12e3561fec517e2079f8043d5... |
|
💔 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 |
bors
added
S-waiting-on-review
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:
DefKind::Modas "crate" #63250 (diagnostics: Describe crate root modules inDefKind::Modas "crate")Failed merges:
r? @ghost