…dation step

Co-Authored-By: Mazdak Farrokhzad <[email protected]>

…ebank"

This reverts commit df21a6f, reversing
changes made to cc16d04.

Co-Authored-By: Aleksey Kladov <[email protected]>

This was missed in PR rust-lang#62293.

Co-Authored-By: Aleksey Kladov <[email protected]>

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.

Clarify align_to's requirements and obligations

Based on discussions with @RalfJung around my misunderstandings when using this.

r? @RalfJung

improve align_offset docs

Cc @shepmaster

…=oli-obk

Make qualify consts in_projection use PlaceRef

r? @oli-obk