use a compatible syntax for grep GNU/BSD

The BSD grep for "basic regex" don't support \| as alternate operator.
Use multiple -e arguments for expressing alternative.

Auto merge of #31358 - japaric:print-targets, r=alexcrichton

that prints a list of all the triples supported by the `--target` flag

r? @alexcrichton

Auto merge of #31524 - jonas-schievink:autoderef, r=steveklabnik

Autoderef in librustc

Autoderef in librustc_borrowck

Autoderef in librustc_lint

Autoderef in librustc_metadata

Autoderef in librustc_mir

Autoderef in librustc_passes

Autoderef in librustc_plugin

Autoderef in librustc_privacy

Autoderef in librustc_resolve

Autoderef in librustc_trans

Autoderef in librustc_typeck

Use more autoderef in libsyntax

Use more autoderef in libsyntax_ext

Use more autoderef in rustc_driver

Make more use of autoderef in librustc_front

Auto merge of #30726 - GuillaumeGomez:compile-fail, r=brson

r? @brson
cc @alexcrichton

I still need to add error code explanation test with this, but I can't figure out a way to generate the `.md` files in order to test example source codes.

Will fix #27328.

Auto merge of #31550 - Stebalien:fix-color, r=nrc

Fixes #31546

rustc: add a `--print target-list` command

Auto merge of #31583 - petrochenkov:indi_ast, r=Manishearth

cc #31487
plugin-[breaking-change]

The AST part of https://github.com/rust-lang/rust/pull/30087

r? @Manishearth

Auto merge of #31541 - tomaka:more-emscripten, r=brson

r? @brson

Auto merge of #31368 - JohanLorenzo:dont-strip-if-test-build, r=alexcrichton

Tools which rely on DWARF for generating code coverage report, don't generate accurate numbers on test builds. For instance, [this sample main](https://github.com/JohanLorenzo/rust-testing-example/blob/757bdbf3887f43db9771c20cb72dfc32aa8f4321/src/main.rs) returns [100% coverage](https://coveralls.io/builds/4940156/source?filename=main.rs) when [kcov](https://github.com/SimonKagstrom/kcov/) runs.

With @pnkfelix 's great help, we could narrow down the issue: The linker strips unused function during phase 6. Here's a patch which stops stripping when someone calls `rustc --test $ARGS`. @pnkfelix wasn't sure if we should add a new flag, or just use --test. What do you think @alexcrichton ?

Also, I'm not too sure: where is the best place to add a test for this addition?

Thanks for the help!

Auto merge of #30830 - arcnmx:static-extern, r=alexcrichton

See #29676

r? @alexcrichton

Auto merge of #31123 - alexcrichton:who-doesnt-want-two-build-systems, r=brson

This series of commits adds the initial implementation of a new build system for
the compiler and standard library based on Cargo. The high-level architecture
now looks like:

1. The `./configure` script is run with `--enable-rustbuild` and other standard
   configuration options.
2. A `Makefile` is generate which proxies commands to the new build system.
3. The new build system has a Python script entry point which manages
   downloading both a Rust and Cargo nightly. This initial script also manages
   building the build system itself (which is written in Rust).
4. The build system, written in rust and called `bootstrap`, architects how to
   call `cargo` and manages building all native libraries and such.

One might reasonably ask "why rewrite the build system?", which is a good
question! The Rust project has used Makefiles for as long as I can remember at
least, and while ugly and difficult to use are undeniably robust as they contain
years worth of tweaking and tuning for working on as many platforms in as many
situation as possible. The rationale behind this PR, however is:

* The makefiles are impenetrable to all but a few people on this
  planet. This means that contributions to the build system are almost
  nonexistent, and furthermore if a build system change is needed it's
  incredibly difficult to figure out how to do so. This hindrance prevents us
  from doing some "perhaps fancier" things we may wish to do in make.

* Our build system, while portable, is unfortunately not infinitely portable
  everywhere.  For example the recently-introduced MSVC target is quite unlikely
  to have `make` installed by default (e.g. it requires building inside of an
  MSYS2 shell currently). Conversely, the portability of make comes at a cost of
  crazy and weird hacks to work around all sorts of versions of software
  everywhere, especially when it comes to the configure script and makefiles.
  By rewriting this logic in one of the most robust platforms there is, Rust,
  we get to assuage all of these worries for free!

* There's a standard tool to build Rust crates, Cargo, but the standard library
  and compiler don't use it. This means that they cannot benefit easily from the
  crates.io ecosystem, nor can the ecosystem benefit from a standard way to
  build this repository itself. Moving to Cargo should help assuage both of
  these needs. This has the added benefit of making the compiler more
  approachable for newbies as working on the compiler will just happen to be
  working on a large Cargo project, all the same standard tools and tricks will
  apply.

* There's a huge amount of portability information in the main distribution, for
  example around cross compiling, compiling on new OSes, etc. Pushing this logic
  into standard crates (like `gcc`) enables the community to immediately benefit
  from new build logic.

Despite these benefits, it's going to be a long road to actually replace our
current build system. This PR is just the beginning and doesn't implement the
full suite of functionality as the current one, but there are many more to
follow! The current implementation strategy hopes to look like:

1. Land a second build system in-tree that can be itereated on an and
   contributed to. This will not be used just yet in terms of gating new commits
   to the repo.
2. Over time, bring the second build system to feature parity with the old build
   system, start setting up CI for both build systems.
3. At some point in the future, switch the default to the new build system, but
   keep the old one around.
4. At some further point in the future, delete the entire old build system.

---

Alright, so with all that out of the way, here's some more info on this PR
itself. The inital build system here is contained in the `src/bootstrap`
directory and just adds the necessary minimum bits to bootstrap the compiler
itself. There is currently no support for building documentation, running tests,
or installing, but the implemented support is:

* Compiling LLVM with `cmake` instead of `./configure` + `make`. The LLVM
  project is removing their autotools build system, so we'd have to make this
  transition eventually anyway.

* Compiling compiler-rt with `cmake` as well (for the same rationale as above).

* Adding `Cargo.toml` to map out the dependency graph to all crates, and also
  adding `build.rs` files where appropriate. For example `alloc_jemalloc` has a
  script to build jemalloc, `flate` has a script to build `miniz.c`, `std` will
  build `libbacktrace`, etc.

* Orchestrating all the calls to `cargo` to build the standard distribution,
  following the normal bootstrapping process. This also tracks dependencies
  between steps to ensure cross-compilation targets happen as well.

* Configuration is intended to eventually be done through a `config.toml` file,
  so support is implemented for this. The most likely vector of configuration
  for now, however, is likely through `config.mk` (what `./configure` emits), so
  the build system currently parses this information.

There's still quite a few steps left to do, and I'll open up some follow-up
issues (as well as a tracking issue) for this migration, but hopefully this is a
great start to get going! This PR is currently tested on all the
Windows/Linux/OSX triples for x86\_64 and x86, but more portability is always
welcome!

---

Future functionality left to implement

* [ ] Re-verify that multi-host builds work
* [ ] Verify android build works
* [ ] Verify iOS build work (mostly compiler-rt)
* [ ] Verify sha256 and ideally gpg of downloaded nightly compiler and nightly rustc
* [ ] Implement testing -- this is a huge bullet point with lots of sub-bullets
* [ ] Build and generate documentation (plus the various tools we have in-tree)
* [ ] Move various src/etc scripts into Rust -- not sure how this interacts with `make` build system
* [ ] Implement `make install` - like testing this is also quite massive
* [x] Deduplicate version information with makefiles

Auto merge of #31545 - dotdash:no_noalias, r=alexcrichton

LLVM's memory dependence analysis doesn't properly account for calls
that could unwind and thus effectively act as a branching point. This
can lead to stores that are only visible when the call unwinds being
removed, possibly leading to calls to drop() functions with b0rked
memory contents.

As there is no fix for this in LLVM yet and we want to keep
compatibility to current LLVM versions anyways, we have to workaround
this bug by omitting the noalias attribute on &mut function arguments.
Benchmarks suggest that the performance loss by this change is very
small.

Thanks to @RalfJung for pushing me towards not removing too many
noalias annotations and @alexcrichton for helping out with the test for
this bug.

Fixes #29485

Remove some unnecessary indirection from AST structures

rustc_back: Fix disabling jemalloc

When building with Cargo we need to detect `feature = "jemalloc"` to enable
jemalloc, so propagate this same change to the build system to pass the right
`--cfg` argument.

configure: Add an option to use the cargo build system

This commit adds a `--enable-rustbuild` option to the configure script which
will copy a different `Makefile.in` into place to intercept all `make`
invocations.

Currently this makefile only has one target, but it's expected to be filled out
quite a bit over time!

rustc_llvm: Tweak how initialization is performed

Refactor a bit to have less repetition and #[cfg] and try to bury it all inside
of a macro.

rustbook: Make `main` a public function

This will allow it to be used as a crate in a Cargo-based build

bootstrap: Add directives to not double-link libs

Have all Cargo-built crates pass `--cfg cargobuild` and then add appropriate
`#[cfg]` definitions to all crates to avoid linking anything if this is passed.
This should help allow libstd to compile with both the makefiles and with Cargo.

bootstrap: Add build scripts for crates

This commits adds build scripts to the necessary Rust crates for all the native
dependencies. This is currently a duplication of the support found in mk/rt.mk
and is my best effort at representing the logic twice, but there may be some
unfortunate-and-inevitable divergence.

As a summary:

* alloc_jemalloc - build script to compile jemallocal
* flate - build script to compile miniz.c
* rustc_llvm - build script to run llvm-config and learn about how to link it.
  Note that this crucially (and will not ever) compile LLVM as that would take
  far too long.
* rustdoc - build script to compile hoedown
* std - script to determine lots of libraries/linkages as well as compile
  libbacktrace

bootstrap: Add a bunch of Cargo.toml files

These describe the structure of all our crate dependencies.

Auto merge of #31083 - SimonSapin:set_port, r=alexcrichton

As demonstrated in the `resolve_socket_addr` change, this is less awkward than re-creating a new address from the other parts.

If this is to be accepted, pleas open a tracking issue (I can’t set the appropriate tags) and I’ll update the PR with the tracking issue number.

configure: Remove default NDK path value

This likely isn't always valid, and subverts auto-detection.

bootstrap: Read configuration from config.mk

During the transition period where we're still using ./configure and makefiles,
read some extra configuration from `config.mk` if it's present. This means that
the bootstrap build should be configured the same as the original ./configure
invocation.

Eventually this will all be removed in favor of only storing information in
`config.toml` (e.g. the configure script will generate config.toml), but for now
this should suffice.

Add a Cargo-based build system

This commit is the start of a series of commits which start to replace the
makefiles with a Cargo-based build system. The aim is not to remove the
makefiles entirely just yet but rather just replace the portions that invoke the
compiler to do the bootstrap. This commit specifically adds enough support to
perform the bootstrap (and all the cross compilation within) along with
generating documentation.

More commits will follow up in this series to actually wire up the makefiles to
call this build system, so stay tuned!

Pass through diagnostic handler instead

Use find_export_name_attr instead of string literal

Remove link_section and linkage as extern indicators

Only retain external static symbols across LTO

Auto merge of #31532 - tomaka:fix-emscripten, r=brson

Before this PR:

> test result: FAILED. 2039 passed; 327 failed; 2 ignored; 0 measured

After:

> test result: FAILED. 2232 passed; 134 failed; 2 ignored; 0 measured

r? @brson

Auto merge of #31527 - danlrobertson:i15735, r=alexcrichton

After some digging I couldn't find a test for #15735, so I added a simplified version to `run-pass` and tested it against 80a3f45 to ensure it fails.

Add SocketAddrV6::set_flowinfo and set_scope_id

Add `SocketAddr{,V4,V6}::set_ip`.

Add `SocketAddr{,V4,V6}::set_port`.

As demonstrated in the `resolve_socket_addr` change, this is less awkward
than re-creating a new address from the other parts.

Auto merge of #31487 - oli-obk:breaking_batch/ast/unop, r=Manishearth

r? @Manishearth

I just noticed they can't be rolled up (often modifying the same line(s) in imports). So once I reach the critical amount for them to be merged I'll create a PR that merges all of them.

fixup: meta item kind

[breaking-change] don't glob export ast::PathListItem_ variants

[breaking-change] don't glob export ast::StrStyle variants

[breaking-change] don't glob export ast::Visibility variants

[breaking-change] don't glob export ast::TraitItemKind variants

[breaking-change] don't glob export ast::Mutablity variants

[breaking-change] don't glob export ast::MetaItem_

[breaking-change] don't glob export ast::MacStmtStyle

[breaking-change] don't glob export ast::KleeneOp variants

[breaking-change] don't glob export ast::Item_ variants

[breaking-change] don't glob export ast::ForeignItem_ variants

[breaking-change] don't pub export ast::Stmt_ variants

[breaking-change] don't pub export ast::IntLitType variants

[breaking-change] don't pub export ast::Lit_ variants

[breaking-change] don't pub export ast::Ty_ variants

[breaking-change] remove unused enum ast::PrimTy

remove unit test that can't be tested anymore

[breaking-change] remove the sign from integer literals in the ast

[breaking-change] don't glob export ast::{UintTy, IntTy} variants

[breaking-change] don't glob export ast::FloatTy variants

[breaking-change] don't glob export ast::Expr_ variants

[breaking-change] don't glob export ast::ExplicitSelf_ variants

[breaking-change] don't glob export ast::Decl_ variants

[breaking-change] don't glob export ast::CaptureClause variants

[breaking-change] don't glob import/export syntax::abi enum variants

[breaking-change] don't glob export ast::BlockCheckMode variants

[breaking-change] don't glob import ast::FunctionRetTy variants

[breaking-change] don't glob export ast::BinOp_

[breaking-change] don't glob export ast::UnOp variants

Auto merge of #31525 - antonblanchard:powerpc64_merge4, r=alexcrichton

We no longer have a separate powerpc64 and powerpc64le target_arch, and instead use target_endian to select between the two. These patches fix a couple of remaining issues.

Add -C link-dead-code option r=alexcrichton

Turning gc-sections off improves code coverage based for tools which
use DWARF debugging information (like kcov). Otherwise dead code is
stripped and kcov returns a coverage percentage that doesn't reflect
reality.

Auto merge of #31507 - dirk:dirk/fix-rustdoc-undeclared-type-ice, r=nrc

Fixes #31451.

Auto merge of #31357 - rthomas:hashers, r=alexcrichton

add a public hasher function for HashSet and HashMap

Add a public hasher function for HashSet and HashMap

Auto merge of #31461 - jseyfried:remove_import_resolutions, r=nrc

This PR adds to `NameBinding` so it can more fully represent bindings from imports as well from items, refactors away `Target`, generalizes `ImportResolution` to a simpler type `NameResolution`, and uses a single `NameResolution`-valued map in place the existing maps `children` and `import_resolutions` (of `NameBinding`s and `ImportResolution`s, respectively), simplifying duplicate checking and name resolution.

It also unifies the `resolve_name_in_module` in `lib.rs` with its namesake in `resolve_imports.rs`, clarifying and improving the core logic (fixes #31403 and fixes #31404) while maintaining clear future-comparability with shadowable globs (i.e., never reporting that a resolution is a `Success` or is `Failing` unless this would also be knowable with shadowable globs).

Since it fixes #31403, this is technically a [breaking-change], but it is exceedingly unlikely to cause breakage in practice. The following is an example of code that would break:
```rust
mod foo {
    pub mod bar {} // This defines bar in the type namespace
    pub use alpha::bar; // This defines bar in the value namespace

    // This should define baz in both namespaces, but it only defines baz in the type namespace.
    pub use self::bar as baz;
    pub fn baz() {} // This should collide with baz, but now it does not.
}

pub fn f() {}
mod alpha {
    pub use self::f as bar; // Changing this to `pub fn bar() {}` causes the collision right now.
    pub use super::*;
}
```

r? @nrc

Auto merge of #31479 - kamalmarhubi:fmt-pointer-unsized, r=alexcrichton

This allows printing pointers to unsized types with the {:p} formatting
directive. The following impls are extended to unsized types:
 - impl<'a, T: ?Sized> Pointer for &'a T
 - impl<'a, T: ?Sized> Pointer for &'a mut T
 - impl<T: ?Sized> Pointer for *const T
 - impl<T: ?Sized> Pointer for *mut T
 - impl<T: ?Sized> fmt::Pointer for Box<T>
 - impl<T: ?Sized> fmt::Pointer for Rc<T>
 - impl<T: ?Sized> fmt::Pointer for Arc<T>

Don't assume color=always when explicitally specified

Fixes #31546

Auto merge of #31409 - alexcrichton:command-exec, r=aturon

These commits are an implementation of https://github.com/rust-lang/rfcs/pull/1359 which is tracked via https://github.com/rust-lang/rust/issues/31398. The `before_exec` implementation fit easily with the current process spawning framework we have, but unfortunately the `exec` implementation required a bit of a larger refactoring. The stdio handles were all largely managed as implementation details of `std::process` and the `exec` function lived in `std::sys`, so the two didn't have access to one another.

I took this as a sign that a deeper refactoring was necessary, and I personally feel that the end result is cleaner for both Windows and Unix. The commits should be separated nicely for reviewing (or all at once if you're feeling ambitious), but the changes made here were:

* The process spawning on Unix was refactored in to a pre-exec and post-exec function. The post-exec function isn't allowed to do any allocations of any form, and management of transmitting errors back to the parent is managed by the pre-exec function (as it's the one that actually forks).
* Some management of the exit status was pushed into platform-specific modules. On Unix we must cache the return value of `wait` as the pid is consumed after we wait on it, but on Windows we can just keep querying the system because the handle stays valid.
* The `Stdio::None` variant was renamed to `Stdio::Null` to better reflect what it's doing.
* The global lock on `CreateProcess` is now correctly positioned to avoid unintended inheritance of pipe handles that other threads are sending to their child processes. After a more careful reading of the article referenced the race is not in `CreateProcess` itself, but rather the property that handles are unintentionally shared.
* All stdio management now happens in platform-specific modules. This provides a cleaner implementation/interpretation for `FromFraw{Fd,Handle}` for each platform as well as a cleaner transition from a configuration to what-to-do once we actually need to do the spawn.

With these refactorings in place, implementing `before_exec` and `exec` ended up both being pretty trivial! (each in their own commit)

Workaround LLVM optimizer bug by not marking &mut pointers as noalias

LLVM's memory dependence analysis doesn't properly account for calls
that could unwind and thus effectively act as a branching point. This
can lead to stores that are only visible when the call unwinds being
removed, possibly leading to calls to drop() functions with b0rked
memory contents.

As there is no fix for this in LLVM yet and we want to keep
compatibility to current LLVM versions anyways, we have to workaround
this bug by omitting the noalias attribute on &mut function arguments.
Benchmarks suggest that the performance loss by this change is very
small.

Thanks to @RalfJung for pushing me towards not removing too many
noalias annotations and @alexcrichton for helping out with the test for
this bug.

Fixes #29485

Auto merge of #31455 - tmiasko:expected-tokens, r=alexcrichton

Previously when breaking tokens into smaller pieces, the replace_token
function have been used. It replaced current token and updated span
information, but it did not clear the list of expected tokens, neither
did it update remaining info about last token. This could lead to
incorrect error message, like one described in the issue #24780:

    expected one of ... `>` ...  found `>`

More emscripten test fixes

std: Move constant back to where it needs to be

Lost track of this during the std::process refactorings

std: Use macros from libc instead of locally

Helps cut down on #[cfg]!

std: Implement CommandExt::exec

This commit implements the `exec` function proposed in [RFC 1359][rfc] which is
a function on the `CommandExt` trait to execute all parts of a `Command::spawn`
without the `fork` on Unix. More details on the function itself can be found in
the comments in the commit.

[rfc]: https://github.com/rust-lang/rfcs/pull/1359

cc #31398

std: Push process stdio setup in std::sys

Most of this is platform-specific anyway, and we generally have to jump through
fewer hoops to do the equivalent operation on Windows. One benefit for Windows
today is that this new structure avoids an extra `DuplicateHandle` when creating
pipes. For Unix, however, the behavior should be the same.

Note that this is just a pure refactoring, no functionality was added or
removed.

std: Lift out Windows' CreateProcess lock a bit

The function `CreateProcess` is not itself unsafe to call from many threads, the
article in question is pointing out that handles can be inherited by unintended
child processes. This is basically the same race as the standard Unix
open-then-set-cloexec race.

Since the intention of the lock is to protect children from inheriting
unintended handles, the lock is now lifted out to before the creation of the
child I/O handles (which will all be inheritable). This will ensure that we only
have one process in Rust at least creating inheritable handles at a time,
preventing unintended inheritance to children.

std: Rename Stdio::None to Stdio::Null

This better reflects what it's actually doing as we don't actually have an
option for "leave this I/O slot as an empty hole".

std: Push Child's exit status to sys::process

On Unix we have to be careful to not call `waitpid` twice, but we don't have to
be careful on Windows due to the way process handles work there. As a result the
cached `Option<ExitStatus>` is only necessary on Unix, and it's also just an
implementation detail of the Unix module.

At the same time. also update some code in `kill` on Unix to avoid a wonky
waitpid with WNOHANG. This was added in 0e190b9a to solve #13124, but the
`signal(0)` method is not supported any more so there's no need to for this
workaround. I believe that this is no longer necessary as it's not really doing
anything.

std: Implement CommandExt::before_exec

This is a Unix-specific function which adds the ability to register a closure to
run pre-exec to configure the child process as required (note that these
closures are run post-fork).

cc #31398

std: Refactor process spawning on Unix

* Build up the argp/envp pointers while the `Command` is being constructed
  rather than only when `spawn` is called. This will allow better sharing of
  code between fork/exec paths.
* Rename `child_after_fork` to `exec` and have it only perform the exec half of
  the spawning. This also means the return type has changed to `io::Error`
  rather than `!` to represent errors that happen.

Auto merge of #30686 - wesleywiser:rustdoc_display_since, r=steveklabnik

Here's some screenshots after this change:


I tried to click through the `std` docs and make sure everything that can have stability attributes has it rendered but I'm probably missing some. I'd also appreciate any feedback on the css changes. I had difficulty getting the `since` labels aligning correctly for enum variants. If anyone has a better idea for that, I'd be glad to implement it.

Fixes #27607