The `align_offset` method returns an `usize`, so using `add` makes more sense than using `offset`, which takes an `isize`.

They were resolved with modern hygiene, making this just a strange way
to shadow lifetimes.

Declarations were already modernized, resulting in cases where a macro
couldn't resolve it's own identifier.

Fixes rust-lang#52632

Existential types (soon to be 'impl trait' aliases) can either be
delcared at a top-level crate/module scope, or within another item such
as an fn. Previously, we were handling the second case incorrectly when
recursively searching for defining usages - we would check children of
the item, but not the item itself. This lead to us missing closures
that consituted a defining use of the existential type, as their opaque
type instantiations are stored in the TypeckTables of their parent
function.

This commit ensures that we explicitly visit the defining item itself,
not just its children.

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

…ass.

I'm relatively certain that SWIG was only needed for LLDB which is no
longer built, and I'm hoping we can remove the xz install to remove the
reliance on `brew` for our build (which is another point of failure for
flaky networks).

In testing 4-core machines on Azure the `realpath_works_tricky` test in
the standard library is failing with "The directory name is invalid". In
attempting to debug this test I was able to reproduce the failure
locally on my machine, and after inspecing the test it I believe is
exploiting Unix-specific behavior that seems to only sometimes work on
Windows. Specifically the test basically executes:

    mkdir -p a/b
    mkdir -p a/d
    touch a/f
    ln -s a/b/c ../d/e
    ln -s a/d/e ../f

and then asserts that `canonicalize("a/b/c")` and
`canonicalize("a/d/e")` are equivalent to `a/f`. On Windows however the
first symlink is a "directory symlink" and the second is a file symlink.
In both cases, though, they're pointing to files. This means that for
whatever reason locally and on the 4-core environment the call to
`canonicalize` is failing. On Azure today it seems to be passing, and
I'm not entirely sure why. I'm sort of presuming that there's some sort
of internals going on here where there's some global Windows setting
which makes symlinks behavior more unix-like and ignore the directory
hint.

In any case this should keep the test working and also fixes the test
locally for me.

Remove mentions of removed `offset_to` method from `align_offset` docs

The `offset_to` method was deleted in rust-lang#52814.

The replacement for the removed method is `wrapping_offset_from`. However, neither method takes an `usize` as argument, so I don't think that it makes sense to mention them.

…ead, r=estebank

Syntax: Recover on `for ( $pat in $expr ) $block`

Fixes rust-lang#62724 by adding some recovery:

```
error: unexpected closing `)`
  --> $DIR/recover-for-loop-parens-around-head.rs:10:23
   |
LL |     for ( elem in vec ) {
   |         --------------^
   |         |
   |         opening `(`
   |         help: remove parenthesis in `for` loop: `elem in vec`
```

The last 2 commits are drive-by cleanups.

r? @estebank

…hton

Impl Debug for Chars

Closes rust-lang#62947, making `Debug` more consistent with the struct's output and purpose

Let me know any feedback!

…petrochenkov

Make generic parameters always use modern hygiene

* E0263 (lifetime parameter declared twice in the same scope) now compares modernized identifiers.
* Const parameters are now resolved with modern hygiene.

Closes rust-lang#58307
Closes rust-lang#60746
Closes rust-lang#61574
Closes rust-lang#62433

Add very simple edition check to tidy.

Fixes rust-lang#58099.

…r=cramertj

Properly check the defining scope of existential types

Fixes rust-lang#52632

Existential types (soon to be 'impl trait' aliases) can either be
delcared at a top-level crate/module scope, or within another item such
as an fn. Previously, we were handling the second case incorrectly when
recursively searching for defining usages - we would check children of
the item, but not the item itself. This lead to us missing closures
that consituted a defining use of the existential type, as their opaque
type instantiations are stored in the TypeckTables of their parent
function.

This commit ensures that we explicitly visit the defining item itself,
not just its children.

… r=varkor

Add tests for some `existential_type` ICEs

Fix rust-lang#53678
Fix rust-lang#60407
Fix rust-lang#60564

rust-lang#54899 will need some minimization before it can be added.

r? @varkor

vxworks: Remove Linux-specific comments.

It looks like the VxWorks fork inadvertently left in some Linux-specific workaround comments in `libstd`, these can be removed. Came up when looking into rust-lang#62516

CC:  @BaoshanPang

…troalbini

ci: Skip installing SWIG/xz on OSX

I'm relatively certain that SWIG was only needed for LLDB which is no
longer built, and I'm hoping we can remove the xz install to remove the
reliance on `brew` for our build (which is another point of failure for
flaky networks).

…ievink

Add links to None in Option doc

r? @jonas-schievink

…t, r=sfackler

std: Fix a failing `fs` test on Windows

In testing 4-core machines on Azure the `realpath_works_tricky` test in
the standard library is failing with "The directory name is invalid". In
attempting to debug this test I was able to reproduce the failure
locally on my machine, and after inspecing the test it I believe is
exploiting Unix-specific behavior that seems to only sometimes work on
Windows. Specifically the test basically executes:

    mkdir -p a/b
    mkdir -p a/d
    touch a/f
    ln -s a/b/c ../d/e
    ln -s a/d/e ../f

and then asserts that `canonicalize("a/b/c")` and
`canonicalize("a/d/e")` are equivalent to `a/f`. On Windows however the
first symlink is a "directory symlink" and the second is a file symlink.
In both cases, though, they're pointing to files. This means that for
whatever reason locally and on the 4-core environment the call to
`canonicalize` is failing. On Azure today it seems to be passing, and
I'm not entirely sure why. I'm sort of presuming that there's some sort
of internals going on here where there's some global Windows setting
which makes symlinks behavior more unix-like and ignore the directory
hint.

In any case this should keep the test working and also fixes the test
locally for me. It's also worth pointing out that this test was made Windows compatible in rust-lang#31360, a pretty ancient PR at this point.

Add syntactic and semantic tests for rest patterns, i.e. `..`

As per my first note in rust-lang#62254 (comment) this adds syntactic and semantic tests for `..` ("rest") patterns which were implemented in rust-lang#62550.

r? @estebank