-> `rustc --target armv7-none-eabi` will work

also build rust-std (rustup) components for them

-> `rustup target add armv7-none-eabi` will work

…D 13.0-CURRENT i386

rust-nightly has been failing to link since 2019-12-10 with variations of
```
 = note: ld: error: relocation R_386_PC32 cannot be used against symbol __rust_probestack; recompile with -fPIC
          >>> defined in /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libcompiler_builtins-6570a75fe85f0e1a.rlib(compiler_builtins-6570a75fe85f0e1a.compiler_builtins.2i519eqi-cgu.15.rcgu.o)
          >>> referenced by std.4xivr03c-cgu.14
          >>>               std-9bd70afd58e204b7.std.4xivr03c-cgu.14.rcgu.o:(_$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h1c78ed6e734a2bfc (.llvm.10122419023709863394)) in archive /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libstd-9bd70afd58e204b7.rlib

          ld: error: relocation R_386_PC32 cannot be used against symbol __rust_probestack; recompile with -fPIC
          >>> defined in /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libcompiler_builtins-6570a75fe85f0e1a.rlib(compiler_builtins-6570a75fe85f0e1a.compiler_builtins.2i519eqi-cgu.15.rcgu.o)
          >>> referenced by std.4xivr03c-cgu.14
          >>>               std-9bd70afd58e204b7.std.4xivr03c-cgu.14.rcgu.o:(std::io::util::copy::h9115f048f2203467) in archive /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libstd-9bd70afd58e204b7.rlib
          clang-cpp: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error

error: could not compile `rustc_macros`.
```
Full log: http://beefy17.nyi.freebsd.org/data/head-i386-default/p523508_s356869/logs/rust-nightly-1.42.0.20200118.log

AFAICT it stopped building after bumping compiler_builtins to 0.1.22
in rust-lang#67110.

Adds a compiler option to allow rustc compile a crate without linking.
With this flag, rustc serializes codegen_results into a .rlink file.

Previous implementation used a single mode type to store various pieces
of otherwise loosely related information:

* Whether debuginfo mode is in use or not.
* Which debuggers should run in general.
* Which debuggers are enabled for particular test case.

The new implementation introduces a separation between those aspects.
There is a single debuginfo mode parametrized by a debugger type.
The debugger detection is performed first and a separate configuration
is created for each detected debugger. The test cases are gathered
independently for each debugger which makes it trivial to implement
support for `ignore` / `only` conditions.

Functional changes:

* A single `debuginfo` entry point (rather than `debuginfo-cdb`, `debuginfo-gdb+lldb`, etc.).
* Debugger name is included in the test name.
* Test outputs are placed in per-debugger directory.
* Fixed spurious hash mismatch. Previously, the config mode would change
  from `DebugInfoGdbLldb` (when collecting tests) to `DebugInfoGdb` or
  `DebugInfoLldb` (when running them) which would affect hash computation.
* PYTHONPATH is additionally included in gdb hash.
* lldb-python and lldb-python-dir are additionally included in lldb hash.

`TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases, the burden of proof should be with the caller, so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error, rather than silently ignoring it or ICEing.

it needs some upstream changes in the build script of the compiler-builtins
crate

The diagnostic for diagnostic for methods and trait provided
methods would only show the empty string:

    error[E0277]: the `?` operator can only be used in  that returns `Result` or `Option` (or another type that implements `std::ops::Try`)

Handle the missing cases so it reads ``a method'' / ``an async
method'' / ``a trait method'' respectively.

Signed-off-by: Philipp Gesang <phg@phi-gamma.net>

Signed-off-by: Philipp Gesang <phg@phi-gamma.net>

As suggested by @Centril.

Signed-off-by: Philipp Gesang <phg@phi-gamma.net>

We already have ownership of the base path, so no need to clone it (within
Path::with_extension).

Clarify where the clippy used in `./x.py clippy` is coming from.
It uses whatever clippy binary was installed via rustup, cargo-install
or otherwise and does NOT use the binary generated by `./x.py build src/tools/clippy`.

[experiment] Add `-Z no-link` flag

Adds a compiler option to allow rustc compile a crate without linking.
With this flag, `rustc` serializes codegen_results into a `.rlink` file.

Part of Issue rust-lang#64191

…crichton

add bare metal ARM Cortex-A targets to rustc

-> `rustc --target armv7a-none-eabi` will work

also build rust-std (rustup) components for them

-> `rustup target add armv7a-none-eabi` will work

this completes our bare-metal support of ARMv7 cores on stable Rust (by 1.42 or 1.43)

(these target specifications have been tested on a real (no emulation / QEMU) [Cortex-A7 core](https://github.com/iqlusioninc/usbarmory.rs/))

…ichton

Unbreak linking with lld 9 on FreeBSD 13.0-CURRENT i386

Add -Wl,-znotext to default linker flags to link with lld 9 on FreeBSD 13.0-CURRENT i386 where rust-nightly has been failing to link since 2019-12-10 with variations of
```
 = note: ld: error: relocation R_386_PC32 cannot be used against symbol __rust_probestack; recompile with -fPIC
          >>> defined in /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libcompiler_builtins-6570a75fe85f0e1a.rlib(compiler_builtins-6570a75fe85f0e1a.compiler_builtins.2i519eqi-cgu.15.rcgu.o)
          >>> referenced by std.4xivr03c-cgu.14
          >>>               std-9bd70afd58e204b7.std.4xivr03c-cgu.14.rcgu.o:(_$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h1c78ed6e734a2bfc (.llvm.10122419023709863394)) in archive /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libstd-9bd70afd58e204b7.rlib

          ld: error: relocation R_386_PC32 cannot be used against symbol __rust_probestack; recompile with -fPIC
          >>> defined in /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libcompiler_builtins-6570a75fe85f0e1a.rlib(compiler_builtins-6570a75fe85f0e1a.compiler_builtins.2i519eqi-cgu.15.rcgu.o)
          >>> referenced by std.4xivr03c-cgu.14
          >>>               std-9bd70afd58e204b7.std.4xivr03c-cgu.14.rcgu.o:(std::io::util::copy::h9115f048f2203467) in archive /wrkdirs/usr/ports/lang/rust-nightly/work/rustc-nightly-src/build/i686-unknown-freebsd/stage1/lib/rustlib/i686-unknown-freebsd/lib/libstd-9bd70afd58e204b7.rlib
          clang-cpp: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error

error: could not compile `rustc_macros`.
```
Full log: http://beefy17.nyi.freebsd.org/data/head-i386-default/p523508_s356869/logs/rust-nightly-1.42.0.20200118.log

AFAICT it stopped building after bumping compiler_builtins to 0.1.22 in rust-lang#67110.

Make `TooGeneric` error in WF checking a proper error

`TooGeneric` is encountered during WF checking when we cannot determine that a constant involving a generic parameter will always be evaluated successfully (rather than resulting in an error). In these cases, the burden of proof should be with the caller, so that we can avoid post-monomorphisation tim errors (which was the previous previous behaviour). This commit ensures that this situation produces a proper compiler error, rather than silently ignoring it or ICEing.

Fixes rust-lang#66962.

r? @eddyb

…excrichton

compiletest: Simplify multi-debugger support

Previous implementation used a single mode type to store various pieces
of otherwise loosely related information:

* Whether debuginfo mode is in use or not.
* Which debuggers should run in general.
* Which debuggers are enabled for particular test case.

The new implementation introduces a separation between those aspects.
There is a single debuginfo mode parametrized by a debugger type.
The debugger detection is performed first and a separate configuration
is created for each detected debugger. The test cases are gathered
independently for each debugger which makes it trivial to implement
support for `ignore` / `only` conditions.

Functional changes:

* A single `debuginfo` entry point (rather than `debuginfo-cdb`, `debuginfo-gdb+lldb`, etc.).
* Debugger name is included in the test name.
* Test outputs are placed in per-debugger directory.
* Fixed spurious hash mismatch. Previously, the config mode would change
  from `DebugInfoGdbLldb` (when collecting tests) to `DebugInfoGdb` or
  `DebugInfoLldb` (when running them) which would affect hash computation.
* PYTHONPATH is additionally included in gdb hash.
* lldb-python and lldb-python-dir are additionally included in lldb hash.

Micro-optimize OutputFilenames

For example, its methods consume 6% of time during debug-compiling a `warp` example:
![Screenshot (debug-compiling a `warp` example)](https://user-images.githubusercontent.com/7091080/72780288-d74f1580-3c61-11ea-953b-34e59ca682f9.png)

This PR optimize them a bit by using `PathBuf::set_extension` instead of `Path::with_extension`, to avoid cloning `PathBuf` excessively.

Export weak symbols used by MemorySanitizer

Export weak symbols defined by MemorySanitizer instrumentation, which are used
to implement `-Zsanitizer-memory-track-origins` and `-Zsanitizer-recover=memory`.
Previously, when using fat LTO, they would internalized and eliminated.

Fixes rust-lang#68367.

Fix try-op diagnostic in E0277 for methods

For methods the try-op diagnostic displays the empty string where
it has more descriptive strings like “a function” otherwise:

    error[E0277]: the `?` operator can only be used in  that returns `Result` or `Option` (or another type that implements `std::ops::Try`)
                                                      ^^
       | |             ^^ cannot use the `?` operator in  that returns `()`
                                                        ^^

I’m seeing this on nightly (rustc 1.42.0-nightly (b5a3341
2020-01-20)) and [on the playpen](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=0e7ce7792c2aceb8056941710d539124).

The changeset add strings for impl methods and trait provided
methods and test cases for the option type.

…lacrum

bootstrap: update clippy subcmd decription

Clarify where the clippy used in `./x.py clippy` is coming from.
It uses whatever clippy binary was installed via rustup, cargo-install
or otherwise and does NOT use the binary generated by `./x.py build src/tools/clippy`.

…ulacrum

pprust: use as_deref

Some drive-by cleanup.

librustc_mir: don't allocate vectors where slices will do.