Miri's pointer_offset_inbounds implementation has been moved into
librustc_mir as ptr_offset_inbounds (to avoid breaking miri on a
nightly update). The comments have been slightly reworked to better
match `offset`'s external documentation about what causes UB.

The intrinsic implementations are taken directly from miri.

Signed-off-by: Joe Richey <joerichey@google.com>

Signed-off-by: Joe Richey <joerichey@google.com>

Signed-off-by: Joe Richey <joerichey@google.com>

Signed-off-by: Joe Richey <joerichey@google.com>

Introduce function attribute corresponding to the `const`/`pure`
attributes supported by GCC, clang and other compilers.

Based on the work of gnzlbg <gonzalobg88@gmail.com>.

Based on the work of gnzlbg <gonzalobg88@gmail.com>.

…able book

Based on the work of gnzlbg <gonzalobg88@gmail.com>.

When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be impenetrable to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.

This only applies when Microsoft's link tool is expected. Not `lld-link` or other MSVC compatible linkers.

This lint checks that all declarations for extern fns of the same name
are declared with the same types.

- Allow ClashingExternDecl for lint-dead-code-3
- Update test case for rust-lang#5791
- Update test case for rust-lang#1866
- Update extern-abi-from-macro test case

Add a lint to catch clashing `extern` fn declarations.

Closes rust-lang#69390.

Adds lint `clashing_extern_decl` to detect when, within a single crate, an extern function of the same name is declared with different types. Because two symbols of the same name cannot be resolved to two different functions at link time, and one function cannot possibly have two types, a clashing extern declaration is almost certainly a mistake.

This lint does not run between crates because a project may have dependencies which both rely on the same extern function, but declare it in a different (but valid) way. For example, they may both declare an opaque type for one or more of the arguments (which would end up distinct types), or use types that are valid conversions in the language the extern fn is defined in. In these cases, we can't say that the clashing declaration is incorrect.

r? @eddyb

Make pointer offset methods/intrinsics const

Implements rust-lang#71499 using [the implementations from miri](https://github.com/rust-lang/miri/blob/52f5d202bdcfe8986f0615845f8d1647ab8a2c6a/src/shims/intrinsics.rs#L96-L112). However, unlike the miri implementation, I made the implementation a single function for both `offset` and `arith_offset`.

I added some tests what's allowed and what's UB. Let me know if any other cases should be added.

CC: @RalfJung @oli-obk

Experimentally add `ffi_const` and `ffi_pure` extern fn attributes

Add FFI function attributes corresponding to clang/gcc/... `const` and `pure`.

Rebased version of rust-lang#58327 by @gnzlbg with the following changes:

- Switched back from the `c_ffi_const` and `c_ffi_pure` naming to `ffi_const` and `ffi_pure`, as I agree with rust-lang#58327 (comment) and this nicely aligns with `ffi_returns_twice`
- (Hopefully) took care of all of @hanna-kruppe's change requests in the original PR

r? @hanna-kruppe

…ts, r=Amanieu

Make `std::char` functions and constants associated to `char`.

First step to fix rust-lang#71763.

rustc-book: Document `-Z strip=val` option

cc rust-lang#72110

…ochenkov

Suggest installing VS Build Tools in more situations

When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be [impenetrable](https://pastebin.com/MRMCr7HM) to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.

This only applies when Microsoft's link tool is expected.

…r=ecstatic-morse

Remove unused `StableHashingContext::node_to_hir_id` method

cc rust-lang#50928

…eklabnik

FIX - Char documentation for unexperienced users

This is my first PR on rust and even if I've read [CONTRIBUTING.md](https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-requests) I'm ensure everything is perfect. Sorry if I didn't follow the exact procedure.

**What it does:**
- Add an example in the char documentation

**Explanation**
Unexperienced users might not know that punctuation is `Case_Ignorable` and not `Uppercase` and `Lowercase` which mean that when checking if a string is uppercase one might be tempted to write:
```rust
my_string.chars().all(char::is_uppercase)
```

However this will return false for `"HELLO WORLD"` which is not intuitive. Since the function `is_case_ignorable` doesn't exists I believe the correct way to check is:
```rust
!my_string.chars().any(char::is_lowercase)
```

The aim of this example is to prevent unexperienced users to make an error which punctuation chars.

llvm: Expose tiny code model to users

This model is relevant to embedded AArch64 targets and was added to LLVM relatively recently (https://reviews.llvm.org/D49673, mid 2018), so rustc frontend didn't provide access to it with `-C code-model`. The gcc analogue is [`-mcmodel=tiny`](https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html).
(This is one of the options that are passed directly to LLVM without being interpreted by rustc.)

Follow up to rust-lang#72248.