Remove bitrig support from rust
Resolves#60743
using `find` and `rg` I delete every occurence of "bitrig" in the sources, expect for the llvm submodule (is this correct?).
There's also this file 5b8e99bb61/rls-analysis/test_data/rust-analysis/libstd-af9bacceee784405.json which contains a bitrig string in it. What to do with that?
submodules: update clippy from 3710ec59 to ad3269c4
Changes:
````
Rustfmt all the things
Clippy dogfood
Update for compiletest changes
Use symbols instead of strings
Rustup to rustc 1.36.0-nightly (1764b2972 2019-05-12)
Add regression test for identity_conversion FP
UI test cleanup: Extract many_single_char_names tests
Add tests for empty_loop lint
Add in_macro again
Rename in_macro to in_macro_or_desugar
````
r? @oli-obk
Changes:
````
Rustfmt all the things
Clippy dogfood
Update for compiletest changes
Use symbols instead of strings
Rustup to rustc 1.36.0-nightly (1764b2972 2019-05-12)
Add regression test for identity_conversion FP
UI test cleanup: Extract many_single_char_names tests
Add tests for empty_loop lint
Add in_macro again
Rename in_macro to in_macro_or_desugar
````
Make tests compatible with musl host
As an alternative to passing explicit linker all over the place I could try linking `cc` to musl gcc since this bootstraps itself.
Assigning for discussion:
r? @alexcrichton
Omit the vendor component in the WASI triple
This renames wasm32-unknown-wasi to wasm32-wasi, omitting the vendor
component. This follows aarch64-linux-android, x86_64-fuchsia, and others in
omitting the vendor field, which has the advantage of aligning with the
[multiarch tuple](https://wiki.debian.org/Multiarch/Tuples), and of being
less noisy.
r? @alexcrichton
This renames wasm32-unknown-wasi to wasm32-wasi, omitting the vendor
component. This follows aarch64-linux-android, x86_64-fuchsia, and others in
omitting the vendor field, which has the advantage of aligning with the
[multiarch tuple](https://wiki.debian.org/Multiarch/Tuples), and of being
less noisy.
conditionally modify darwin targets to macosx targets with versions
We need this behavior so that Rust LLVM IR objects match the target triple for Clang LLVM IR objects. This matching then convinces the linker that yes, you really can do cross-language LTO with objects from different compilers.
The newly-added tests seem to pass locally on x86_64-unknown-linux-gnu. I haven't done a full test run or tried the new compiler in an cross-language LTO setup yet.
submodules: update clippy from 2ed0b3bf to fc96aa03
Changes:
````
Rustup to rustc 1.36.0-nightly (13fde05b1 2019-05-03)
Fix link in into_iter_on_array documentation
remove function body from "too many args" span
check closure arguments before use it
format code
fix suggestion for search_is_some
fix suggestion for search_is_some naively
change |&x| to |x| in stderr file
cargo fmt
useless_let_if_seq handle interior mutability
````
Fixes https://github.com/rust-lang/rust/issues/60534
Changes:
````
Rustup to rustc 1.36.0-nightly (13fde05b1 2019-05-03)
Fix link in into_iter_on_array documentation
remove function body from "too many args" span
check closure arguments before use it
format code
fix suggestion for search_is_some
fix suggestion for search_is_some naively
change |&x| to |x| in stderr file
cargo fmt
useless_let_if_seq handle interior mutability
````
`find_attr_val(&line, "since")` returns `Some(", issue = ")` when
`line` is set to the following line:
```
[unstable(feature = "checked_duration_since", issue = "58402")]
```
Make `find_attr_val` use regex that is a little bit more
precise (requires `=` after key name).
It still does not handle all cases (e.g., extra leading chars in key
name, or escaped quotes in value), but is good enough for now.
PGO: Add a run-make test that makes sure that PGO profiling data is used by the compiler during optimizations.
From the tests comment section:
```
# This test makes sure that PGO profiling data leads to cold functions being
# marked as `cold` and hot functions with `inlinehint`.
# The test program contains an `if` were actual execution only ever takes the
# `else` branch. Accordingly, we expect the function that is never called to
# be marked as cold.
```
r? @alexcrichton
In JSON output, emit a directive after metadata is generated.
To implement pipelining, Cargo needs to know when metadata generation is
finished. This is done via a new JSON "directive".
Unfortunately, metadata file writing currently occurs very late during
compilation, so pipelining won't produce a speed-up. Moving metadata
file writing earlier will be a follow-up.
r? @alexcrichton