-> `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.

`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 <[email protected]>

Signed-off-by: Philipp Gesang <[email protected]>

As suggested by @Centril.

Signed-off-by: Philipp Gesang <[email protected]>

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

For now, this is all the crate contains, but more
attribute logic & types will be moved there over time.

2. invert rustc_session & syntax deps
3. drop rustc_session dep in rustc_hir

2. as a result, drop rustc_errors dep from syntax

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`.

Slimmer syntax

High-level summary of changes:

- The `syntax::node_count` pass is moved into `rustc_ast_passes`. This works towards improving rust-lang#65031 by making compiling `syntax` go faster.

- The `syntax::{GLOBALS, with_globals, ..}` business is consolidated into `syntax::attr` for cleaner code and future possible improvements.

- The pretty printer loses its dependency on `ParseSess`, opting to use `SourceMap` & friends directly instead.

- Some drive by cleanup of `syntax::attr::HasAttr` happens.

- Builtin attribute logic (`syntax::attr::builtin`) + `syntax::attr::allow_internal_unstable` is moved into a new `rustc_attr` crate. More logic from `syntax::attr` should be moved into that crate over time. This also means that `syntax` loses all mentions of `ParseSess`, which enables the next point.

- The pretty printer `syntax::print` is moved into a new crate `rustc_ast_pretty`.

- `rustc_session::node_id` is moved back as `syntax::node_id`. As a result, `syntax` gets to drop dependencies on `rustc_session` (and implicitly `rustc_target`), `rustc_error_codes`, and `rustc_errors`. Moreover `rustc_hir` gets to drop its dependency on `rustc_session` as well. At this point, these crates are mostly "pure data crates", which is approaching a desirable end state.

  - We should consider renaming `syntax` to `rustc_ast` now.

…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

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`.